Open lucb1e opened 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.
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.
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.
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.
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
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
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.
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?
Hey @laurentS yes. The official client should take care of that though.
Describe the bug
Websites and bittorrent trackers receive the user's IPv6 address while they are connected to the VPN.
To Reproduce
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:
Desktop (please complete the following information):
ProtonVPN-CLI v2.2.2
(cloned from the repository, commita5f1c61a
)Additional context
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.ufw
enabled as well as disabled. After disabling, I disconnected and reconnected the VPN to make sure any rules/scripts are applied/run again.