ProtonVPN Additional note: Killswitch failure and IP Leakage on Linux

[anon61138815]

@anon36227541

Fedora’s default vpn settings can leak? Ive been setting up wireguadd configs using fedora’s default graphical UI in the settings.

The IPV6 address leaks in the default configuration. I tested it less than a week ago. It has been like this since I first tested it three years ago.

Edit:
Be sure to disable IPV6 on your Wi-Fi/Ethernet network and keep the DNS resolver at the distribution default, and everything will run smoothly without leaks.

Be sure to follow the advice of other forum members to enable the permanent Killswitch or at least the automatic connection to the profile when manually adding the Wireguard profile, since when you restart your computer, Fedora may automatically connect to Wi-Fi without automatically connecting to the Wireguard profile.

@Breeze7846

the leak is not present after the daemon runs?

It happens even when connected to a server.

@Anvil

It’s also often recommended to bind your torrent client to the VPN interface to prevent leaks like this.

I agree.

However, a recommended Torrent application when opening Flathub, called Fragments (recommended by Gnome Circle), does not offer this option.

This leak also does not occur when using Windscribe’s permanent Killswitch, which I tested before switching to Proton.

@Encounter5729

This would potentially involve a compromised application. I don’t say this shouldn’t be mentionned, but any application that is unsandboxed and compromised could do worst things.

It could also involve a valid application that makes requests of this type. If there is one, I am unaware of it. In this case, the user would leak their IP address.

Or the scenario of some exploitation whose sole motivation is to de-anonymize the user.

@Encounter5729

Things to determine is:

1- Can all apps run ifconfig (to get interface name) and then curl? What about Flatpaks apps?
2- Are the two other recommended VPNs impacted (Mullvad and IVPN)?
3-Is this limited to Linux or macOS as well?

1. I don’t know.

2. It is valid to answer this question in order to compare the Killswitch of VPN providers. Anyone with a subscription to these tools can test it. If the other recommended providers face the same problem, another topic can be opened, requesting notes to be added to the site if the other providers do not implement a fix within a reasonable time. Outside of these situations, this discussion is off-topic.

3. This is a discussion exclusively about Linux. This discussion is off-topic.

@anon4692472

I appreciate what you say, and once again, stressing my lack of technical knowledge - but is this not akin to opening a drain valve on a piping system and saying “look - a leak!”

No, since the function of Killswitch is to prevent any type of leak on any interface, unless the user explicitly chooses to allow that interface, application, etc., to access the internet outside the VPN tunnel. Another scenario is one in which the platform prevents the full application of the VPN, as is the case with Android, which makes calls outside the tunnel. This is a known scenario and is transparently disclosed to the public.

Any other scenario where an interface, application, etc., accesses the internet with the advanced/permanent Killswitch turned on can be considered a bug.

It is also important to take into account the linked article and what the blog author said.

@anon61138815

Article: ProtonVPN IP Leakage on Linux and Workaround | PrivSec - A practical approach to Privacy and Security

”I sent Proton an email regarding this issue in late August 2022 and was told they are working on fixing it, though it will take some time as it requires some architectural changes in how the killswitch works.”

@Encounter5729

I tested it on Android with termux and it is also affected, as long as you don’t have “Block connections without VPN” activated.

My memory may be failing me, and I apologize if that is the case, but when “Block connections without VPN” is disabled, other applications may leak your IP address using their own protocols. Some privileged Google services may also access the internet outside the tunnel even when “Block connections without VPN” is enabled.

Please correct me if I am wrong.

In any case, although Android is based on Linux, it is a mobile platform and is built differently, beyond the topic of the Linux desktop environment.

It would be appropriate to open another topic to talk about Android.

@Anvil

Not really, in my view kill switch not kill switching is basically false advertising.

I completely agree.

What made me decide to switch to another VPN provider a few years ago was a bug in Proton’s Killswitch that allowed network connections when the computer came out of sleep mode in Windows.

I currently use Linux, so the above problem does not affect me. Although I remember testing it on Linux at the time, I don’t recall the test results, since it wouldn’t have affected me then, as I decided to switch back to Windows.

@Anvil

My understanding of how vpns work on android is that this is not really proton’s fault. If you want a kill switch on android you have to use the block connections setting

Excellent explanation.

—
Thank you to everyone who is participating in this discussion. Your contributions are valuable.

[anon98749087]

At the risk of going slightly off topic…

I agree that privacy guides should at a minimum provide very clear warnings (like at the very beginning of any recommendations) when issues like this are known. (Removing recommendations completely may also be warranted.)

Basically, proton doesn’t warn users about these dangerous flaws (and sometimes is directly misleading). If privacy guides doesn’t at a minimum provide clear warnings (ex. “Do not use this on Linux if you need a functional kill switch.”) then they are participating in leading users into unsafe situations that they did not consent to or expect. I realize bugs come up, and they probably can’t respond to all of them, but in issues where apps have long-standing issues, or a provider is known to have repeated issues (even if only on a particular OS) (both of these are true with proton)…that is kinda akin to having findings from a security audit and not responding to them.

I honestly cannot see recommending use of any proton apps on Linux at this point, they are so full of bugs and broken features. The proton pass app on Linux no longer auto locks for example (on fedora workstation), and this was a. a purposeful design feature, and b. repeatedly defended as being correct by multiple different proton customer service reps. Linux is the only recommended desktop os, and proton does an absysmal job of supporting basically any of their products on Linux. Why isn’t this more clear on the PG recommendations?

[jonah (Jonah Aragon)]

This topic remains an issue.

@jonah

The completely different problem to the macOS one that Proton has on Linux, which is described at ProtonVPN IP Leakage on Linux and Workaround | PrivSec - A practical approach to Privacy and Security remains an issue (which I confirmed with testing of course).

The question here, I think, is whether this is a big enough problem to still consider Proton in violation of our current criteria, especially given that Proton specifically says to bind programs like torrent clients to the tunnel interface directly, which does solve this problem.

To be clear, the kill switch on Linux is fully functional, unless an application specifically binds to the physical network interface. This, to me, seems like an issue which would warrant using something like Qubes, if protecting access to the physical network interface is of utmost importance to you, so I’d really consider this a platform limitation of Linux more than a Proton failure. Linux being extremely permissive with what you can do with it is a double-edged sword in this regard.

I think the community is generally of two minds about this:

@jonah

@ignoramous

No.

Thank you for your analysis. I will share the most likely counterpoint for people to consider:

I think it’s probably fair to argue that on Linux you should be aware of what you are installing and what those programs are doing. A kill switch in this scenario that applies to the default network configuration is mainly going to protect you from random disconnects, while an intentionally misconfigured program set to bypass the kill switch by binding to a specific interface could be considered out of scope for what a mere software kill switch has to be doing.

This is compounded by the fact that the way to implement a kill switch on Linux is highly variable depending on distro and network configuration, there isn’t a single system API to plug into like on Android. In some sense if you are going to be performing sensitive tasks on Linux then you need to configure them properly, and if you don’t trust yourself and/or the application you need to be using the tool for the job that prevents this problem by design, which is Qubes.

Like I said, it’s an open question I’m presenting to everyone here, and I don’t really lean towards this argument one way or the other. I think…

@ignoramous

If programs can bypass a VPN tunnel by merely binding to a specific interface, then that’s a leak, and definitely a ‘killswitch’ that’s horribly broken.

…is also a perfectly valid opinion to hold, and if this is what we want to say then we could still de-list Proton. I don’t think it’s unreasonable to instead simply add a warning about this edge-case either though.

It sounds to me like the consensus from this thread in December is generally that this behavior warrants a warning. What do we think?

---

@Encounter5729

Does it have real world impact?

The significance does seem unclear to me, but probably minimal. I’m leaning towards it requiring a warning, maybe in our general VPN overview since a lot of VPNs on Linux seem to require additional configuration from what I can tell. See for example: ProtonVPN IP Leakage on Linux and Workaround - #2 by anon88979181

[fiqiluvo.epileto]

@jonah

To be clear, the kill switch on Linux is fully functional

It isn’t and developers have to constantly fight with networkmanager, systemd resolved, dhclient, resolvconf quirks. Hence why Proton and Mullvad state the officially supported OSes that are claimed to be tested to have no leaks. An average Linux user doesn’t even know that his wg-quick command will result in ipv6 leaks (reminding myself to paste a citation straight from this forum), or that networkmanager usage might lead to dns leakage due to dns priority or ignore-auto-dns.

PG should ideally mention those facts. dngray has great points regarding VPN clients on the consumer OSes.

@jonah

while an intentionally misconfigured program set to bypass the kill switch by binding to a specific interface could be considered out of scope for what a mere software kill switch has

not relying on glibc or musl to make syscalls and handle dns caching themselves is bad coding?

ProtonVPN is 100% guilty of leaking on Linux, i can tell you that without going through test suite. Legitimate programs get confused about the default binded interface all the time.

[jonah (Jonah Aragon)]

For what it’s worth, at the moment I believe the most reasonable solution to this is to add a section to our VPN overview article saying that software kill switches shouldn’t be relied upon, and if you need greater assurance you should use Qubes or a dedicated external hardware device (router) that locally-running software cannot interfere with.

I would probably prefer this over adding a warning to Proton VPN specifically about this problem, although I suppose we could do both.

[dadnerd]

I think this is the correct answer. The known instances where VPN clients have leaks are going to shift so frequently that it will be hard to keep up with updating the notes. I mostly care about our user base having fair warning that their kill switch likely isn’t giving them 100% protection. Adding this note would address that concern. It will also raise awareness for VPN on router, which I think is a great solution.

[fiqiluvo.epileto]

On Linux in particular, an ideal test suite would take a bunch of network managers with their upstream configuration and test VPN clients against them, then make the same tests on Debian, Fedora and other stable distros that are known to reconfigure the software to their liking and draw conclusions from this. A criteria for removal would be false marketing, i.e if a VPN client advertises compatibility with certain distros while not combating with its networkmanager configuration enough. Or not making the right filter rules like Proton does at all.

Additionally, many of the lesser VPN services are providing guides for wg-quick because they don’t have Linux client. I’ve tested a bunch of them and can confidently say that they all leak. PG should warn users about these pitfalls.

[ignoramous]

@jonah

bypass the kill switch by binding to a specific interface could be considered out of scope for what a mere software kill switch has to be doing

Why? Binding to a network interface isn’t some dark arts. It is very normal and a very usual thing for programs using the BSD socket APIs to do. ‘Killswitch’ is expected to cover this.

@jonah

single system API to plug into like on Android

The series of actions Android performs (when that “single system API” is invoked) to create a ‘killswitch’ would not look all too different to what one would do on a mainstream Linux distro with net admin capability / root.

---

@jonah

VPN overview article saying that software kill switches shouldn’t be relied upon, and if you need greater assurance you should use Qubes or a dedicated external hardware device (router) that locally-running software cannot interfere with

@dngray

What in saying that crappy software kill switches aren’t really reliable?

What?! May be I misread what you two are suggesting… but just in case…

External hardware routers cannot act like a killswitch for an OS (without help from a locally operating software killswitch) because the external hardware is so far removed from the OS/Kernel that’s making decisions on network traffic, that the OS/Kernel might very well take a routing decision that also bypasses that external hardware router (for instance, connect via another radio).

[jonah (Jonah Aragon)]

@ignoramous

the OS/Kernel might very well take a routing decision that also bypasses that external hardware router (for instance, connect via another radio).

I’m not sure I follow. I feel like your computer randomly reaching out to some network you didn’t connect it to is very outside the scope of what is reasonable? I guess if we feel otherwise then enforcing a single network path via Qubes (similar to Whonix for example) is our only path here?

---

To be clear, the intent behind recommending an external router would be to essentially re-create a Whonix-like networking setup (minus Tor) in hardware instead of VMs. This is something I mainly bring up only because I have seen @dngray discuss this option, so he would need to elaborate further here.

[fiqiluvo.epileto]

@dadnerd

It will also raise awareness for VPN on router, which I think is a great solution.

I’ve tested a bunch of OpenWRT forks and know for a fact GL inet routers are leaky, for example. Merely stating the existence of VPN routers isn’t enough as people will inevitably follow bad/uninformed advices.

I don’t think it’s impossible for PG to keep up with the VPN leaks on Linux if we define the testing scope the right way.

But right now PG doesn’t even mention the specific kinds of VPN leaks on Android. The decision to omit ProtonVPN recommendations on Linux should also be made as it is known to be leaky.

[dadnerd]

Off-topic

@fiqiluvo.epileto

I’ve tested a bunch of OpenWRT forks and know for a fact GL inet routers are leaky, for example.

Which scenarios do these routers leak?

[fiqiluvo.epileto]

@ignoramous

The series of actions Android performs (when that “single system API” is invoked) to create a ‘killswitch’ would not look all too different to what one would do on a mainstream Linux distro with net admin capability / root.

Granted they wouldn’t be overridden by a network manager or other software. Software routing gives the user a false sense of safety. While people generally know not to run 2 VPN clients at once, it’s not commonly understood that the OS components do misbehave. It’s sensible to state that software routing on complex consumer OSes shouldn’t be trusted.

@ignoramous

that the OS/Kernel might very well take a routing decision that also bypasses that external hardware router (for instance, connect via another radio).

I think thats precisely the case for a DIY distro/QubesOS or a router as they are expected to behave as intended.

[ignoramous]

@jonah

I feel like your computer randomly reaching out to some network you didn’t connect it to is very outside the scope of what is reasonable?

How would you enforce any “computer” not randomly reach out to another network without enforcing that via “software killswitches,” which we also claim are inadequate? That is, external killswitches are useless without a corresponding water-tight on-computer software killswitch (which is the Qubes / Whonix setup, from what I gather).

One doesn’t replace the other, I don’t think. In Qubes / Whonix’s case, physical isolation (employing a physically separate router) is mandated to mitigate VM/OS exploits (from what I can tell) cc: @dadnerd who knows more, probably.

[jonah (Jonah Aragon)]

I suppose simply by making the external router the only possible network for the computer to connect to. Certainly could be easier said than done though, so it may not be a solution worth recommending.

[fiqiluvo.epileto]

dnsmasq misconfig resulting in Adguard taking presence over Wireguard’s advertised DNS even when the user haven’t turned the adguard functionality ON. I believe this was fixed.

In my testing, if a Wireguard DNS went down, dnsmasq sent the request to next target that was either DNS over TLS or DHCP DNS endpoint, i can’t remember. Zero Trust VPN tunnel was left on by default on another router and broke the mDNS advertising.

dnsmasq advertising the DNS resolution to the next target if in-tunnel DNS resolution broke for one reason or another. On a Cudy OpenWRT fork, a cached DNS result was sometimes sent to every dnsmasq entry.

@ignoramous

How would you enforce any “computer” not randomly reach out to another network

Like wwan manager instructing the component to connect elsewhere or are implying firmware glitches? In both cases, it can be negated by connecting wired.

@ignoramous

That is, external killswitches are useless without a corresponding water-tight on-computer software killswitch

Qubes approach makes it possible to have a messy user facing OS while having a tight and predictable network VM. With Qubes, in the worst case scenario a user facing VM will loose connection.

We can mimick this by disallowing the host OS to manage wwan and connect to the VPN router directly.

[Encounter5729]

@jonah

The significance does seem unclear to me, but probably minimal. I’m leaning towards it requiring a warning, maybe in our general VPN overview since a lot of VPNs on Linux seem to require additional configuration from what I can tell. See for example: ProtonVPN IP Leakage on Linux and Workaround - #2 by anon88979181

Yeah, I kind of changed my mind. Not sure this specifically has significance, but seeing that their macOS app is also subpar, I do believe we should remove Proton VPN. I guess we might add warnings as some kind of quasi-consensus that’s better than the status quo.

[jonah (Jonah Aragon)]

At the end of the day the primary service a VPN provider is providing is access to the remote servers themselves, and the client is just one factor.

I think we are getting caught up in minor client details here. If we generally agree that the Linux issues aren’t hugely significant, and we generally agree that the macOS issues largely come down to a difference in development philosophies between Proton and Mullvad/IVPN (which we are discussing in a different thread so I don’t want to get into this further here), then it doesn’t really make sense to delist Proton VPN ignoring all the other reasons we recommend them in the first place.

They are still the only provider we list doing things like providing port forwarding, their server count/locations are still reasonably effective at bypassing geo-restrictions (regardless of what you think about many of their locations being “virtual locations”), they are still run by a company that the community generally expects to be trustworthy/transparent about what their servers are running at the end of the day, etc.

[Encounter5729]

I would agree that this issue in itself obviously doesn’t in itself merits delistment. The question is whether the entirety of those issue does IMO.

[dngray (Daniel Gray)]

@anon61138815

curl --interface <physical interface> https://ipinfo.io

The real world impact of that is a misconfigured piece of software could circumvent the kill switch if it binds to the wrong interface. Bittorrent clients are one such example of that.