[BUG] IPv6 leaks - Githubissues

lucb1e commented 4 years ago

Describe the bug

Websites and bittorrent trackers receive the user's IPv6 address while they are connected to the VPN.

To Reproduce

Have a modern internet connection
Connect the VPN as usual - I chose the Netherlands, a P2P server to test bittorrent leaks, and UDP
Go to https://ipleak.net - I used Firefox
IPv4 shows the VPN, IPv6 shows my own IP
Load the magnet link into a bittorrent client - I used Transmission

Expected behavior

Both for the regular and the bittorrent test, the VPN IP(s) should be shown: preferably an IPv6 address from the VPN or, since it's not supported, no IPv6 at all. Instead, my real IP is shown for IPv6.

Error Messages/Program Output/Log Messages (~/.pvpn-cli/pvpn-cli.log)

No errors or warnings shown, this seems to be the relevant IPv6 part:

2020-03-30 16:48:29,188 — protonvpn-cli — DEBUG — manage_ipv6:648 — Disabling IPv6
2020-03-30 16:48:29,189 — protonvpn-cli — DEBUG — manage_ipv6:659 — Backing up ip6tables rules
2020-03-30 16:48:29,202 — protonvpn-cli — DEBUG — manage_ipv6:684 — IPv6 disabled successfully

Desktop (please complete the following information):

OS: Debian 10
Python Version: 3.7.3
ProtonVPN-CLI Version: ProtonVPN-CLI v2.2.2 (cloned from the repository, commit a5f1c61a)

Additional context

In some cases, the DNS test also shows v6, but I can't reliably reproduce this.
Even immediately after connecting, sudo cat /proc/sys/net/ipv6/conf/all/disable_ipv6 = 0. Not sure how it tries to disable v6 but this is the switch I know of and it wasn't flipped.
I tried both with ufw enabled as well as disabled. After disabling, I disconnected and reconnected the VPN to make sure any rules/scripts are applied/run again.

Rafficer commented 4 years ago

It disables IPv6 with iptables rules. Do you have any specific rules set? They usually get cleared but something doesn't seem right.

lucb1e commented 4 years ago

I have the rules set that ufw adds. When ufw is disabled, the remaining rules just trigger some empty chains and all policies are set to accept. It's the same for iptables and ip6tables:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ufw6-before-logging-input  all      anywhere             anywhere            
ufw6-before-input  all      anywhere             anywhere            
ufw6-after-input  all      anywhere             anywhere            
ufw6-after-logging-input  all      anywhere             anywhere            
ufw6-reject-input  all      anywhere             anywhere            
ufw6-track-input  all      anywhere             anywhere            

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ufw6-before-logging-forward  all      anywhere             anywhere            
ufw6-before-forward  all      anywhere             anywhere            
ufw6-after-forward  all      anywhere             anywhere            
ufw6-after-logging-forward  all      anywhere             anywhere            
ufw6-reject-forward  all      anywhere             anywhere            
ufw6-track-forward  all      anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ufw6-before-logging-output  all      anywhere             anywhere            
ufw6-before-output  all      anywhere             anywhere            
ufw6-after-output  all      anywhere             anywhere            
ufw6-after-logging-output  all      anywhere             anywhere            
ufw6-reject-output  all      anywhere             anywhere            
ufw6-track-output  all      anywhere             anywhere            

Chain ufw6-before-logging-input (1 references)
target     prot opt source               destination         

Chain ufw6-before-logging-output (1 references)
target     prot opt source               destination         

Chain ufw6-before-logging-forward (1 references)
target     prot opt source               destination         

Chain ufw6-before-input (1 references)
target     prot opt source               destination         

Chain ufw6-before-output (1 references)
target     prot opt source               destination         

Chain ufw6-before-forward (1 references)
target     prot opt source               destination         

Chain ufw6-after-input (1 references)
target     prot opt source               destination         

Chain ufw6-after-output (1 references)
target     prot opt source               destination         

Chain ufw6-after-forward (1 references)
target     prot opt source               destination         

Chain ufw6-after-logging-input (1 references)
target     prot opt source               destination         

Chain ufw6-after-logging-output (1 references)
target     prot opt source               destination         

Chain ufw6-after-logging-forward (1 references)
target     prot opt source               destination         

Chain ufw6-reject-input (1 references)
target     prot opt source               destination         

Chain ufw6-reject-output (1 references)
target     prot opt source               destination         

Chain ufw6-reject-forward (1 references)
target     prot opt source               destination         

Chain ufw6-track-input (1 references)
target     prot opt source               destination         

Chain ufw6-track-output (1 references)
target     prot opt source               destination         

Chain ufw6-track-forward (1 references)
target     prot opt source               destination

For the nat table:

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

When ufw is enabled, there are rules in the custom chains and the INPUT and FORWARD chain policies change to drop, but since IPv6 also leaks with empty rules (ufw disabled), I guess it doesn't really matter what specific rules it sets when ufw is enabled.

70rc commented 4 years ago

I can confirm this. At least from earlier observations, haven't tried in a while. My guess is that IPv6 traffic matches one of the UFW rules, and as the PVPN rules are added after those, they are never matched, and IPv6 traffic thus passes. The only solutions I've found so far is to either disable UFW or IPv6 at the kernel level. As for the leaks with disabling UFW, I think I resolved this by disabling UFW, then rebooting, then connecting to PVPN. I think disabling UFW doesn't completely revert IPtables, only a subsequent reboot does. Though this is from a distant memory, but maybe worth a try.

sidebuster commented 4 years ago

I have the same problem with a semi fresh install on Pop!_OS 19.10 5.3.0-7648-generic with UFW enabled but with no rules.

Disabling UFW both by command "ufw disable" and "systemctl disable ufw.service" then restarting fixed the issue. This is a new issue as well that I hadn't had previously.

barrosfelipe commented 4 years ago

Same problem here in Pop! OS 20.04 LTS running 5.4.0-7629-generic. After reading this issue, this is what I did to mitigate this problem: edit /etc/default/ufw and set IPV6=no disable ufw with sudo ufw disable reboot enable ufw again with sudo ufw enable connect to protonvpn

TheNightRider12 commented 4 years ago

I had this same issue. My real IP was showing alongside the VPN's IP on ipleak.net. Doing the steps below fixed the issue for me.

> Same problem here in Pop! OS 20.04 LTS running 5.4.0-7629-generic. After reading this issue, this is what I did to mitigate this problem:
> edit `/etc/default/ufw` and set `IPV6=no`
> disable ufw with `sudo ufw disable`
> reboot
> enable ufw again with `sudo ufw enable`
> connect to protonvpn

barrosfelipe commented 4 years ago

This is a serious bug. It exposes the user’s real IP address, thereby defeating the purpose of using a VPN—and it’s silent. Perhaps many ProtonVPN customers are feeling safe while being affected by this. Any updates @Rafficer ? It has been almost three months since the creation of this issue.

laurentS commented 3 years ago

I'm having this issue as well. According to the help page, ipv6 is not supported, but there are no comments there past 2018. Is this still the case?

calexandru2018 commented 3 years ago

Hey @laurentS yes. The official client should take care of that though.

Rafficer / linux-cli-community

[BUG] IPv6 leaks #143