rickjames 106 Posted ... Thank you for the reply, but I do have network lock enabled (I always do). It's still leaking private ipv4 however. Hello! We don't see this leak... anyway, how is that a problem? Kind regards You're the expert in this conversation, not me Is it not a problem? I imagine that it could identify me, or at the very least, might identify me. I think not everyone has the same private ipv4, do they? If that is true, imagine I am using a VPN server which has 20 users. If only 25% have the same private ipv4, then it's pretty much down to 5 users. Is my thinking wrong? Edit NVM I see you're on chrome.Google is the information king. WebRTC fix or not using anything google is far from ideal if you're concerned about privacy. Edited. Quote Share this post Link to post
ofiris 15 Posted ... Thank you for the reply, but I do have network lock enabled (I always do). It's still leaking private ipv4 however. Hello! We don't see this leak... anyway, how is that a problem? Kind regards You're the expert in this conversation, not me Is it not a problem? I imagine that it could identify me, or at the very least, might identify me. I think not everyone has the same private ipv4, do they? If that is true, imagine I am using a VPN server which has 20 users. If only 25% have the same private ipv4, then it's pretty much down to 5 users. Is my thinking wrong? Edit NVM I see you're on chrome.Google is the information king. WebRTC fix or not using anything google is far from ideal if you're concerned about privacy. Edited. It's chromium actually. Quote Share this post Link to post
rickjames 106 Posted ... Thank you for the reply, but I do have network lock enabled (I always do). It's still leaking private ipv4 however. Hello! We don't see this leak... anyway, how is that a problem? Kind regards You're the expert in this conversation, not me Is it not a problem? I imagine that it could identify me, or at the very least, might identify me. I think not everyone has the same private ipv4, do they? If that is true, imagine I am using a VPN server which has 20 users. If only 25% have the same private ipv4, then it's pretty much down to 5 users. Is my thinking wrong? Edit NVM I see you're on chrome.Google is the information king. WebRTC fix or not using anything google is far from ideal if you're concerned about privacy. Edited. It's chromium actually. Its core is still google. Test on a different browser at least and rule out other issues. Quote Share this post Link to post
Clodo 176 Posted ... I am doing some research about it. http://www.reddit.com/r/VPN/comments/32d94q/an_alternative_approach_to_socalled_webrtc_leaks/ Quote Share this post Link to post
Zaroad 26 Posted ... Comodo Firewall blocks WebRTC if you set it properly, although private IP still leaks Quote Share this post Link to post
ofiris 15 Posted ... https://nls.io/blog/stop-webrtc-leak-in-chrome Apparently, there's a fix for chrome(ium) 42+... Sadly, that version is not yet available for ubuntu. I wonder how long it'll take for it to be available in the repos.. Quote Share this post Link to post
silverstrings 0 Posted ... https://nls.io/blog/stop-webrtc-leak-in-chrome Apparently, there's a fix for chrome(ium) 42+... Sadly, that version is not yet available for ubuntu. I wonder how long it'll take for it to be available in the repos..Hey everyone. New guy here. Been using Airvpn for a while now, and keeping an eye on this thread. Anyway, the above fix in the above link does work for me on Chrome 42. Quote Share this post Link to post
Hades666 1 Posted ... https://nls.io/blog/stop-webrtc-leak-in-chrome Apparently, there's a fix for chrome(ium) 42+... Sadly, that version is not yet available for ubuntu. I wonder how long it'll take for it to be available in the repos.. This works for me too with ipleak.net and the link provided with the guide. Quote Share this post Link to post
CriticalRabbit 6 Posted ... Hi, I use Firefox mainly but wanted an additional browser for work related things. I decided to go with Opera. However, when I’ve checked IPleaks.net, I get a WebRTC detection ‘Private IPv4 detected’. I have the latest Eddie installed, with the network lock on. I’m currently using Windows 7. Is this a problem and if so, can it be solved? Cheers, Rabbit Quote Share this post Link to post
altae 22 Posted ... And this is why removing the routing table entry with the "0.0.0.0" mask in Windows will also stop the WebRTC leak. The browser's attempt to "call home" on the real interface (to an STUN server) fails. I would think that this trick does not work on Linux. Hello! This is just a clarification that could be useful for some casual Linux user reading this thread: Linux does not suffer any WebRTC leak so no intervention at all is necessary. Kind regardsSorry but I cannot confirm that. I did the test using Firefox 38. something running in a VM (Vmware Workstation 11) on top of Windows 8.1 (64 bit). The Linux distribution I use is Linux Mint KDE 17.1. It showed my real IP using WebRTC, media.peerconnection.enabled = false fixed it though. The network interface of the VM is set to bridged so the WM gets it's (internal) IP directly from the DHCP server (Fritzbox 7390 router). I did the test more than once and it always showed me my real IP. I don't know if it is kernel and or distribution dependant but at least with my setup Linux is also concerned. 1 encrypted reacted to this Quote Share this post Link to post
Staff 9972 Posted ... And this is why removing the routing table entry with the "0.0.0.0" mask in Windows will also stop the WebRTC leak. The browser's attempt to "call home" on the real interface (to an STUN server) fails. I would think that this trick does not work on Linux. Hello! This is just a clarification that could be useful for some casual Linux user reading this thread: Linux does not suffer any WebRTC leak so no intervention at all is necessary. Kind regardsSorry but I cannot confirm that. I did the test using Firefox 38. something running in a VM (Vmware Workstation 11) on top of Windows 8.1 (64 bit). The Linux distribution I use is Linux Mint KDE 17.1. It showed my real IP using WebRTC, media.peerconnection.enabled = false fixed it though. The network interface of the VM is set to bridged so the WM gets it's (internal) IP directly from the DHCP server (Fritzbox 7390 router). I did the test more than once and it always showed me my real IP. I don't know if it is kernel and or distribution dependant but at least with my setup Linux is also concerned. Thanks! Please see also the following article. It contains information unavailable to us when we first wrote the article. The whole WebRTC approach appears to have been profoundly wrong by many people in the world community. http://www.clodo.it/blog/an-alternative-approach-to-so-called-webrtc-leaks Kind regards 1 altae reacted to this Quote Share this post Link to post
NaDre 157 Posted ... And this is why removing the routing table entry with the "0.0.0.0" mask in Windows will also stop the WebRTC leak. The browser's attempt to "call home" on the real interface (to an STUN server) fails. I would think that this trick does not work on Linux. Hello! This is just a clarification that could be useful for some casual Linux user reading this thread: Linux does not suffer any WebRTC leak so no intervention at all is necessary. Kind regards Sorry but I cannot confirm that. I did the test using Firefox 38. something running in a VM (Vmware Workstation 11) on top of Windows 8.1 (64 bit). The Linux distribution I use is Linux Mint KDE 17.1. It showed my real IP using WebRTC, media.peerconnection.enabled = false fixed it though. The network interface of the VM is set to bridged so the WM gets it's (internal) IP directly from the DHCP server (Fritzbox 7390 router). I did the test more than once and it always showed me my real IP. I don't know if it is kernel and or distribution dependant but at least with my setup Linux is also concerned. I believe the question of whether WebRTC will leak or not on Linux depends on the way routing is set up. Just as for Windows. In any OS, having a program bind a specific interface will only result in traffic being routed over that interface if the routing set up will allow it. And the details of how the routing set up affects this are different for different OSes. It depends on the "Host Model" they use. See: http://en.wikipedia.org/wiki/Host_model For Windows (in its default host model set up), the presence of the original gateway entry with the 0.0.0.0 mask is enough to allow this. See: https://technet.microsoft.com/en-us/magazine/2007.09.cableguy.aspx "If strong host sends are enabled on the source interface, IP performs a constrained lookup of the destination address of the packet in the routing table. In a constrained lookup, only those routes with a next-hop interface of the source interface are considered." Windows is normally configured to use the "Strong" host model. On the other hand, Linux is normally configured to use the "Weak" host model. As a result, only the default gateway from the "main" routing table will ever be used to send traffic, unless an additional routing table is set up to do "source address routing". An example of using source address routing (in the context of running OpenVZ containers) is discussed here: https://openvz.org/Source_based_routing Certainly Debian and Ubuntu come configured to use the weak host model "out of the box". And I think this would be why they do not suffer the WebRTC leak, unless you set up source address routing. This then raises the question: Why are you experiencing the WebRTC leak on Linux? Have you done some source address routing? Is it possible that Linux Mint comes configured as a strong host? I googled for a couple of minutes and did not find a quick answer to that question. Quote Share this post Link to post
altae 22 Posted ... No, I did not change anything concerning routing. Like I wrote I use Linux Mint 17.1 KDE and all I changed is I enabling the built in firewall (GUFW) which to my knowledge is a frontend to iptables. The firewall is set up to deny any incoming traffic exept smb wich I need for sharing. Outgoing traffic is generally allowed. I have never touched anything concerning routing since frankly my knowledge concerning routing etc. is limited and because I don't see a reason why I should change anything given the fact that my network is a simple setup of one pc, connected over ethernet to a switch wich is in turn connected to the router/ modem (Fritzbox 7390). The Fritzbox also comes with a firewall, there any incoming traffic is blocked, outgoing traffic is allowed, no port forwarding. So concerning routing, my system is pretty much out of the box. Quote Share this post Link to post
altae 22 Posted ... In case you don't believe me: Attached are two screenshots. One shows the WebRTC leak because media.peerconnection.enabled = true, one shows there is no leak because media.peerconnection.enabled = false. You can clearly see that whoer.net is able to determine my real IP as well as my network internal IP (both are correct). What more info do you need? Maybe this: Firfox version is 38.0, Linux kernel = 3.16.0-30-generic x86_64 (64 bit). There are also 2 screenshots that show network lock is enabled and dns switch mode is set to automatic. And given the fact that resolv.conf is prensent on my system I guess it uses that method. Well I'm neither a Linux nor a IT security expert but my experience clearly shows that Linux, at least in some configurations, is also affected by the WebRTC leak. Quote Share this post Link to post
NaDre 157 Posted ... I believe you. I just repeated a bunch of testing that I did a while ago. The first time I found that there was no way I could get traffic to go out an interface that was not the default gateway unless I set up source address routing for it. This was a problem because I wanted to use the original default gateway as the default gateway, but use the VPN interface with rtorrent. This is the only reason I ended up learning about source address routing. But just now, my Debian system is behaving exactly like Windows! Beats the hell out of me. But in the end, I don't really care. So long as I can get my systems to do what I want. Have you tried just removing the original gateway entry with the 0.0.0.0 mask? This works on Windows. At least it did the last time I tried it! Otherwise you may have to set up IPTABLES to block all but the OpenVPN traffic from using the real interface, while the VPN is up. Quote Share this post Link to post
altae 22 Posted ... Otherwise you may have to set up IPTABLES to block all but the OpenVPN traffic from using the real interface, while the VPN is up. But isn't that what network lock is supposed to do? Quote Share this post Link to post
Staff 9972 Posted ... Otherwise you may have to set up IPTABLES to block all but the OpenVPN traffic from using the real interface, while the VPN is up. But isn't that what network lock is supposed to do? Hello!Exactly, Network Lock must prevent so called "WebRTC leak". If it occurs anyway maybe you have modified iptables rules after you enabled Network Lock. Which Eddie version are you running? Note that 2.8.8 and older versions did not set properly ip6tables. Kind regards Quote Share this post Link to post
altae 22 Posted ... Like I wrote I have never touched iptables, frankly I don't understand how it works. And I am 100 percent sure that I did not touch iptables after the connection with AirVPN had been established and netlock had been activated. So in my case reality is as follows: - Linux does suffer from the WebRTC leak, the problem is not limited to Windows or OSX.- Netlock does not fix the problem, the real IP still leaks- The only thing that fixes it is media.peerconnection.enabled = false in Firefox. A few words concerning my setup: - IPv6 is disabled using his method Add these lines to the bottom of sysctl.conf net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1 net.ipv6.conf.lo.disable_ipv6 = 1 Then run sudo sysctl -p or reboot - The client is the latest version, 2.9.2 I think it's not correct to assume that the problem is fixed. My real world example (which is reproduceable at any time) clearly shows that, at least on my system, netlock does not fix the WebRTC leak. If you need more info in order to investigate the matter please let me know, I'll gladly help you if I can. Quote Share this post Link to post
Staff 9972 Posted ... Like I wrote I have never touched iptables, frankly I don't understand how it works. And I am 100 percent sure that I did not touch iptables after the connection with AirVPN had been established and netlock had been activated. So in my case reality is as follows: - Linux does suffer from the WebRTC leak, the problem is not limited to Windows or OSX. Hello! It's not a vulnerability. The whole "WebRTC leak" case has been fabricated, probably in good faith, by people who did not understand what they were seeing. It's just an application that binds to a physical network interface, to say it quickly. For a more detailed analysis please see the link in the first message of this thread. - Netlock does not fix the problem, the real IP still leaks We confirm that we can't reproduce what you say after weeks of tests on a bunch of different Linux systems (thanks to the community for dozens of reports on this!). iptables and ip6tables rules block outgoing packets from physical interface except to VPN servers entry-IP addresses, so theoretically that's totally impossible, but let's investigate, there must be something we're missing or something that's peculiar to your system. - IPv6 is disabled using his method Add these lines to the bottom of sysctl.conf net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1 net.ipv6.conf.lo.disable_ipv6 = 1 Then run sudo sysctl -p or reboot Let's see the iptables and ip6tables rules while your system is connected to some VPN server, with Network Lock enabled, listed just after you have managed to get your real IP address via ipleak.net WebRTC test. Please open a terminal as root, issue the following commands and copy and paste everything in your message:iptables-saveip6tables-save Attach also a screenshot of ipleak.net (taking care to delete your real IP address!). netlock does not fix the WebRTC leak. If you need more info in order to investigate the matter please let me know, I'll gladly help you if I can. Yes, we can't reproduce the issue you report and it could be important. Please help us by providing the above requested data, thanks! Kind regards Quote Share this post Link to post
altae 22 Posted ... Ok, I will do so as soon as I get home from work. Quote Share this post Link to post
altae 22 Posted ... Et voilà, here are the desired infos: altaelm171kde altae # iptables-save # Generated by iptables-save v1.4.21 on Wed Jun 3 00:50:16 2015 *mangle :PREROUTING ACCEPT [25879:6702170] :INPUT ACCEPT [25879:6702170] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [25347:2254111] :POSTROUTING ACCEPT [25326:2253572] COMMIT # Completed on Wed Jun 3 00:50:16 2015 # Generated by iptables-save v1.4.21 on Wed Jun 3 00:50:16 2015 *nat :PREROUTING ACCEPT [21:2598] :INPUT ACCEPT [12:2241] :OUTPUT ACCEPT [1026:98290] :POSTROUTING ACCEPT [999:96218] COMMIT # Completed on Wed Jun 3 00:50:16 2015 # Generated by iptables-save v1.4.21 on Wed Jun 3 00:50:16 2015 *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] :ufw-after-forward - [0:0] :ufw-after-input - [0:0] :ufw-after-logging-forward - [0:0] :ufw-after-logging-input - [0:0] :ufw-after-logging-output - [0:0] :ufw-after-output - [0:0] :ufw-before-forward - [0:0] :ufw-before-input - [0:0] :ufw-before-logging-forward - [0:0] :ufw-before-logging-input - [0:0] :ufw-before-logging-output - [0:0] :ufw-before-output - [0:0] :ufw-logging-allow - [0:0] :ufw-logging-deny - [0:0] :ufw-not-local - [0:0] :ufw-reject-forward - [0:0] :ufw-reject-input - [0:0] :ufw-reject-output - [0:0] :ufw-skip-to-policy-forward - [0:0] :ufw-skip-to-policy-input - [0:0] :ufw-skip-to-policy-output - [0:0] :ufw-track-forward - [0:0] :ufw-track-input - [0:0] :ufw-track-output - [0:0] :ufw-user-forward - [0:0] :ufw-user-input - [0:0] :ufw-user-limit - [0:0] :ufw-user-limit-accept - [0:0] :ufw-user-logging-forward - [0:0] :ufw-user-logging-input - [0:0] :ufw-user-logging-output - [0:0] :ufw-user-output - [0:0] -A INPUT -i lo -j ACCEPT -A INPUT -s 255.255.255.255/32 -j ACCEPT -A INPUT -s 192.168.0.0/16 -d 192.168.0.0/16 -j ACCEPT -A INPUT -s 10.0.0.0/8 -d 10.0.0.0/8 -j ACCEPT -A INPUT -s 172.16.0.0/12 -d 172.16.0.0/12 -j ACCEPT -A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -i tun+ -j ACCEPT -A INPUT -j DROP -A FORWARD -i tun+ -j ACCEPT -A FORWARD -j DROP -A OUTPUT -d 192.168.1.156/32 -j ACCEPT -A OUTPUT -d 173.44.55.180/32 -j ACCEPT -A OUTPUT -d 173.44.55.178/32 -j ACCEPT -A OUTPUT -d 96.47.229.60/32 -j ACCEPT -A OUTPUT -d 96.47.229.58/32 -j ACCEPT -A OUTPUT -d 173.44.55.156/32 -j ACCEPT -A OUTPUT -d 173.44.55.154/32 -j ACCEPT -A OUTPUT -d 199.241.147.36/32 -j ACCEPT -A OUTPUT -d 199.241.147.34/32 -j ACCEPT -A OUTPUT -d 199.241.146.164/32 -j ACCEPT -A OUTPUT -d 199.241.146.162/32 -j ACCEPT -A OUTPUT -d 199.241.146.180/32 -j ACCEPT -A OUTPUT -d 199.241.146.178/32 -j ACCEPT -A OUTPUT -d 198.203.28.44/32 -j ACCEPT -A OUTPUT -d 198.203.28.42/32 -j ACCEPT -A OUTPUT -d 94.100.23.164/32 -j ACCEPT -A OUTPUT -d 94.100.23.162/32 -j ACCEPT -A OUTPUT -d 46.21.151.108/32 -j ACCEPT -A OUTPUT -d 46.21.151.106/32 -j ACCEPT -A OUTPUT -d 45.34.11.68/32 -j ACCEPT -A OUTPUT -d 45.34.11.66/32 -j ACCEPT -A OUTPUT -d 149.255.33.156/32 -j ACCEPT -A OUTPUT -d 149.255.33.154/32 -j ACCEPT -A OUTPUT -d 46.21.154.84/32 -j ACCEPT -A OUTPUT -d 46.21.154.82/32 -j ACCEPT -A OUTPUT -d 91.220.163.46/32 -j ACCEPT -A OUTPUT -d 91.220.163.44/32 -j ACCEPT -A OUTPUT -d 103.254.153.100/32 -j ACCEPT -A OUTPUT -d 103.254.153.68/32 -j ACCEPT -A OUTPUT -d 62.102.148.176/32 -j ACCEPT -A OUTPUT -d 62.102.148.136/32 -j ACCEPT -A OUTPUT -d 62.102.148.170/32 -j ACCEPT -A OUTPUT -d 62.102.148.139/32 -j ACCEPT -A OUTPUT -d 62.102.148.178/32 -j ACCEPT -A OUTPUT -d 62.102.148.135/32 -j ACCEPT -A OUTPUT -d 62.102.148.180/32 -j ACCEPT -A OUTPUT -d 62.102.148.134/32 -j ACCEPT -A OUTPUT -d 62.102.148.182/32 -j ACCEPT -A OUTPUT -d 62.102.148.133/32 -j ACCEPT -A OUTPUT -d 62.102.148.184/32 -j ACCEPT -A OUTPUT -d 62.102.148.132/32 -j ACCEPT -A OUTPUT -d 62.102.148.174/32 -j ACCEPT -A OUTPUT -d 62.102.148.137/32 -j ACCEPT -A OUTPUT -d 62.102.148.188/32 -j ACCEPT -A OUTPUT -d 62.102.148.130/32 -j ACCEPT -A OUTPUT -d 62.102.148.186/32 -j ACCEPT -A OUTPUT -d 62.102.148.131/32 -j ACCEPT -A OUTPUT -d 94.185.85.172/32 -j ACCEPT -A OUTPUT -d 94.185.85.170/32 -j ACCEPT -A OUTPUT -d 185.57.80.148/32 -j ACCEPT -A OUTPUT -d 185.57.80.146/32 -j ACCEPT -A OUTPUT -d 109.163.226.155/32 -j ACCEPT -A OUTPUT -d 109.163.230.232/32 -j ACCEPT -A OUTPUT -d 94.46.8.205/32 -j ACCEPT -A OUTPUT -d 94.46.8.203/32 -j ACCEPT -A OUTPUT -d 213.163.74.41/32 -j ACCEPT -A OUTPUT -d 213.163.74.22/32 -j ACCEPT -A OUTPUT -d 213.152.162.100/32 -j ACCEPT -A OUTPUT -d 213.152.162.98/32 -j ACCEPT -A OUTPUT -d 213.152.162.115/32 -j ACCEPT -A OUTPUT -d 213.152.162.113/32 -j ACCEPT -A OUTPUT -d 213.152.162.85/32 -j ACCEPT -A OUTPUT -d 213.152.162.83/32 -j ACCEPT -A OUTPUT -d 109.232.227.150/32 -j ACCEPT -A OUTPUT -d 109.232.227.148/32 -j ACCEPT -A OUTPUT -d 213.152.162.90/32 -j ACCEPT -A OUTPUT -d 213.152.162.88/32 -j ACCEPT -A OUTPUT -d 213.152.162.70/32 -j ACCEPT -A OUTPUT -d 213.152.162.68/32 -j ACCEPT -A OUTPUT -d 109.232.227.139/32 -j ACCEPT -A OUTPUT -d 109.232.227.137/32 -j ACCEPT -A OUTPUT -d 213.152.162.105/32 -j ACCEPT -A OUTPUT -d 213.152.162.103/32 -j ACCEPT -A OUTPUT -d 213.152.162.110/32 -j ACCEPT -A OUTPUT -d 213.152.162.108/32 -j ACCEPT -A OUTPUT -d 213.152.162.95/32 -j ACCEPT -A OUTPUT -d 213.152.162.93/32 -j ACCEPT -A OUTPUT -d 213.152.162.75/32 -j ACCEPT -A OUTPUT -d 213.152.162.73/32 -j ACCEPT -A OUTPUT -d 109.232.227.134/32 -j ACCEPT -A OUTPUT -d 109.232.227.132/32 -j ACCEPT -A OUTPUT -d 109.202.103.171/32 -j ACCEPT -A OUTPUT -d 109.202.103.169/32 -j ACCEPT -A OUTPUT -d 213.152.162.80/32 -j ACCEPT -A OUTPUT -d 213.152.162.78/32 -j ACCEPT -A OUTPUT -d 217.195.49.119/32 -j ACCEPT -A OUTPUT -d 217.195.49.100/32 -j ACCEPT -A OUTPUT -d 217.195.49.104/32 -j ACCEPT -A OUTPUT -d 217.195.49.107/32 -j ACCEPT -A OUTPUT -d 217.195.49.113/32 -j ACCEPT -A OUTPUT -d 217.195.49.101/32 -j ACCEPT -A OUTPUT -d 217.195.49.147/32 -j ACCEPT -A OUTPUT -d 217.195.49.102/32 -j ACCEPT -A OUTPUT -d 103.10.197.188/32 -j ACCEPT -A OUTPUT -d 103.10.197.186/32 -j ACCEPT -A OUTPUT -d 78.129.153.59/32 -j ACCEPT -A OUTPUT -d 78.129.153.40/32 -j ACCEPT -A OUTPUT -d 84.39.116.181/32 -j ACCEPT -A OUTPUT -d 84.39.116.179/32 -j ACCEPT -A OUTPUT -d 84.39.117.58/32 -j ACCEPT -A OUTPUT -d 84.39.117.56/32 -j ACCEPT -A OUTPUT -d 82.145.37.204/32 -j ACCEPT -A OUTPUT -d 82.145.37.202/32 -j ACCEPT -A OUTPUT -d 94.229.74.92/32 -j ACCEPT -A OUTPUT -d 94.229.74.90/32 -j ACCEPT -A OUTPUT -d 46.29.125.15/32 -j ACCEPT -A OUTPUT -d 46.29.125.13/32 -j ACCEPT -A OUTPUT -d 95.215.62.93/32 -j ACCEPT -A OUTPUT -d 95.215.62.91/32 -j ACCEPT -A OUTPUT -d 46.182.35.49/32 -j ACCEPT -A OUTPUT -d 46.182.35.14/32 -j ACCEPT -A OUTPUT -d 178.162.198.112/32 -j ACCEPT -A OUTPUT -d 178.162.198.102/32 -j ACCEPT -A OUTPUT -d 46.165.208.110/32 -j ACCEPT -A OUTPUT -d 46.165.208.69/32 -j ACCEPT -A OUTPUT -d 46.165.208.106/32 -j ACCEPT -A OUTPUT -d 46.165.208.65/32 -j ACCEPT -A OUTPUT -d 178.162.198.110/32 -j ACCEPT -A OUTPUT -d 178.162.198.103/32 -j ACCEPT -A OUTPUT -d 178.162.198.46/32 -j ACCEPT -A OUTPUT -d 178.162.198.40/32 -j ACCEPT -A OUTPUT -d 46.165.208.109/32 -j ACCEPT -A OUTPUT -d 46.165.208.70/32 -j ACCEPT -A OUTPUT -d 50.7.211.252/32 -j ACCEPT -A OUTPUT -d 50.7.211.250/32 -j ACCEPT -A OUTPUT -d 91.214.169.70/32 -j ACCEPT -A OUTPUT -d 91.214.169.68/32 -j ACCEPT -A OUTPUT -d 46.19.137.115/32 -j ACCEPT -A OUTPUT -d 46.19.137.114/32 -j ACCEPT -A OUTPUT -d 198.144.158.15/32 -j ACCEPT -A OUTPUT -d 198.144.158.11/32 -j ACCEPT -A OUTPUT -d 137.63.71.52/32 -j ACCEPT -A OUTPUT -d 137.63.71.50/32 -j ACCEPT -A OUTPUT -d 199.19.94.195/32 -j ACCEPT -A OUTPUT -d 199.19.94.19/32 -j ACCEPT -A OUTPUT -d 104.254.90.196/32 -j ACCEPT -A OUTPUT -d 104.254.90.194/32 -j ACCEPT -A OUTPUT -d 104.254.90.188/32 -j ACCEPT -A OUTPUT -d 104.254.90.186/32 -j ACCEPT -A OUTPUT -d 199.19.94.137/32 -j ACCEPT -A OUTPUT -d 199.19.94.132/32 -j ACCEPT -A OUTPUT -d 184.75.221.4/32 -j ACCEPT -A OUTPUT -d 184.75.221.2/32 -j ACCEPT -A OUTPUT -d 199.19.94.65/32 -j ACCEPT -A OUTPUT -d 199.19.94.61/32 -j ACCEPT -A OUTPUT -d 199.19.95.189/32 -j ACCEPT -A OUTPUT -d 199.19.95.187/32 -j ACCEPT -A OUTPUT -d 104.254.90.252/32 -j ACCEPT -A OUTPUT -d 104.254.90.250/32 -j ACCEPT -A OUTPUT -d 104.254.90.244/32 -j ACCEPT -A OUTPUT -d 104.254.90.242/32 -j ACCEPT -A OUTPUT -d 199.21.149.70/32 -j ACCEPT -A OUTPUT -d 199.21.149.44/32 -j ACCEPT -A OUTPUT -d 104.254.90.236/32 -j ACCEPT -A OUTPUT -d 104.254.90.234/32 -j ACCEPT -A OUTPUT -d 184.75.214.164/32 -j ACCEPT -A OUTPUT -d 184.75.214.162/32 -j ACCEPT -A OUTPUT -d 104.254.90.204/32 -j ACCEPT -A OUTPUT -d 104.254.90.202/32 -j ACCEPT -A OUTPUT -d 199.19.94.18/32 -j ACCEPT -A OUTPUT -d 199.19.94.12/32 -j ACCEPT -A OUTPUT -d 162.219.176.4/32 -j ACCEPT -A OUTPUT -d 162.219.176.2/32 -j ACCEPT -A OUTPUT -d 95.211.138.143/32 -j ACCEPT -A OUTPUT -d 54.225.156.17/32 -j ACCEPT -A OUTPUT -d 54.246.124.152/32 -j ACCEPT -A OUTPUT -d 54.93.175.114/32 -j ACCEPT -A OUTPUT -o lo -j ACCEPT -A OUTPUT -d 255.255.255.255/32 -j ACCEPT -A OUTPUT -s 192.168.0.0/16 -d 192.168.0.0/16 -j ACCEPT -A OUTPUT -s 10.0.0.0/8 -d 10.0.0.0/8 -j ACCEPT -A OUTPUT -s 172.16.0.0/12 -d 172.16.0.0/12 -j ACCEPT -A OUTPUT -o tun+ -j ACCEPT -A OUTPUT -j DROP COMMIT # Completed on Wed Jun 3 00:50:16 2015 altaelm171kde altae # ip6tables-save # Generated by ip6tables-save v1.4.21 on Wed Jun 3 00:55:24 2015 *mangle :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] COMMIT # Completed on Wed Jun 3 00:55:24 2015 # Generated by ip6tables-save v1.4.21 on Wed Jun 3 00:55:24 2015 *nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] COMMIT # Completed on Wed Jun 3 00:55:24 2015 # Generated by ip6tables-save v1.4.21 on Wed Jun 3 00:55:24 2015 *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] :ufw6-after-forward - [0:0] :ufw6-after-input - [0:0] :ufw6-after-logging-forward - [0:0] :ufw6-after-logging-input - [0:0] :ufw6-after-logging-output - [0:0] :ufw6-after-output - [0:0] :ufw6-before-forward - [0:0] :ufw6-before-input - [0:0] :ufw6-before-logging-forward - [0:0] :ufw6-before-logging-input - [0:0] :ufw6-before-logging-output - [0:0] :ufw6-before-output - [0:0] :ufw6-logging-allow - [0:0] :ufw6-logging-deny - [0:0] :ufw6-reject-forward - [0:0] :ufw6-reject-input - [0:0] :ufw6-reject-output - [0:0] :ufw6-skip-to-policy-forward - [0:0] :ufw6-skip-to-policy-input - [0:0] :ufw6-skip-to-policy-output - [0:0] :ufw6-track-forward - [0:0] :ufw6-track-input - [0:0] :ufw6-track-output - [0:0] :ufw6-user-forward - [0:0] :ufw6-user-input - [0:0] :ufw6-user-limit - [0:0] :ufw6-user-limit-accept - [0:0] :ufw6-user-logging-forward - [0:0] :ufw6-user-logging-input - [0:0] :ufw6-user-logging-output - [0:0] :ufw6-user-output - [0:0] -A INPUT -i lo -j ACCEPT -A INPUT -j DROP -A FORWARD -j DROP -A OUTPUT -o lo -j ACCEPT -A OUTPUT -j DROP COMMIT # Completed on Wed Jun 3 00:55:24 2015 As you can see the leak is real. I got this result with the experimental client (2.10.0, portable version) since I'm currently also investigating another issue I have lately encountered. But result is the same using the latest stable client. Quote Share this post Link to post
Staff 9972 Posted ... As you can see the leak is real. I got this result with the experimental client (2.10.0, portable version) since I'm currently also investigating another issue I have lately encountered. But result is the same using the latest stable client. Hello, everything seems fine, the detected IP address is the VPN server exit-IP address. No leaks. Kind regards Quote Share this post Link to post
altae 22 Posted ... Ehm sorry but are you tired (given the fact that it's already past midnight)? You are clearly talking about the IP in big digits. May I ask you to take a look at the IP in small digits just underneath? It shows my internal network IP as well as my external IP which I blackend for privacy reasons. But it's definitely my external IP, I checked it using ifconfig. Quote Share this post Link to post
Staff 9972 Posted ... Ehm sorry but are you tired (given the fact that it's already past midnight)? You are clearly talking about the IP in big digits. May I ask you to take a look at the IP in small digits just underneath? It shows my internal network IP as well as my external IP which I blackend for privacy reasons. But it's definitely my external IP, I checked it using ifconfig. Hello, the private IP address is not a leak. The second IP address (the one you blacked out) should not be your public IP address, that field is not used by ipleak.net for that. It must be your VPN IP address. Can you tell us the left-most octet of this IP address? Kind regards Quote Share this post Link to post
altae 22 Posted ... Well looks like I am the one that is tired here I clearly cofused something. Let me get back to you tomorrow, I really need to get some sleep now. Quote Share this post Link to post
Not connected, Your IP: 3.133.146.94
Online: 26487 users - 337116 Mbit/s total BW.thumb.png.8be84fd39f94c1640ac8c5456fbf3449.png){kind=avatar}