Since the “remove Proton VPN” thread continues to get derailed by people wanting to talk about the restrictions of certain operating systems that prevent a complete kill switch, I thought I’d make this proposal to add more information about the limitations of what VPN kill switches can do on certain platforms to avoid misleading people into thinking 100% of traffic will go through the tunnel regardless of OS.
Also see this relevant thread:
Good thread idea. I would not personally de-list any VPN for its OS specific issues. The issues should be made known and users made aware.
Here are some for sources to start with Android. Obviously I know these issues are not solved so I did a ctrl+c & ctrl+v.
DNS Leaks:
DNS traffic can leak outside the VPN tunnel on Android | Mullvad VPN
VPN leaks DNS traffic outside the tunnel [337961996] - Issue Tracker
Connectivity check leaks:
Android leaks connectivity check traffic | Mullvad VPN
Add option to disable connectivity checks when VPN lockdown is enabled [250529027] - Issue Tracker
GrapheneOS issued fix to these issues but not yet implemented in AOSP
Improved VPN leak blocking - GOS website
There’s 2 issues here:
Issue #2 on Android, for instance, is a limitation stemming from sandboxes an app might be subject to.
Both issue #1 & #2 are a genuine concern, if your threat model says, “Use VPN to hide traffic from ISP”, when no such thing is possible without installing VPN software on the router & hoping the router itself does not have “holes”. This puts in to question the 4 points PG today presents as justification for using a VPN, which are:
Should I use a VPN? Yes, almost certainly. A VPN has many advantages, including:
- Hiding your traffic from only your Internet Service Provider.
- Hiding your downloads (such as torrents) from your ISP and anti-piracy organizations.
- Hiding your IP from third-party websites and services, helping you blend in and preventing IP based tracking.
- Allowing you to bypass geo-restrictions on certain content.
Point #1 is not possible on some platforms (like iOS and Android), either due to missing implementation on the VPN provider’s official client or due to the OS not extending such guarantees to userspace (as in the case of Android and … iOS?).
None of the recommended providers meet Point #2, but may be, there are other providers that do: Clarification on "torrenting" in the VPN page · Issue #3176 · privacyguides/privacyguides.org · GitHub
For VPN client apps, Point #3 (hiding client IP from 3p apps and websites) only holds if the providers implement the OS-provided killswitch.
Point #4 is debatable as some services know VPN IP ranges and will not let you access geo restricted content. Usually, residential proxies are needed to bypass geo-restricted content, but those have nothing to do with VPN providers themselves, and rather involve a very shady network of operators that run proxies on compromised IoT and other Internet-connected devices like Projectors / TVs / Streamboxes / Access Points / etc. Not anything that’s ethical by any stretch of my imagination, but YMMV.
Loopback and localhost between profiles are also sources for IPC and leaks. GrapheneOS is long way away from solving them, so is Android.
Platform leaks are almost impossible to seal in Linux, the recommendation for anyone who wants to strictly obfuscate IP using VPNs should be whonix like setups. Usual VPN setups can only mask IP within browsers and/or if you use dedicated namespaces/network interface bindings for specific applications.
iOS and MacOS are too leaky to even consider. Just use Private relay and don’t buy an iPhone if Apple or state level adversaries (including state ISPs cracking down due to DMCA) are your threat model.
BSDs are good, well documented for network connections, but I don’t think folks use it.
If VPNs (and not tor, not VMs) are a requirement, I think GrapheneOS followed by Android are the only real choices. If someone is willing to tinker, Linux can be sealed using whonix, namespaces, and the like at varying degree of separation.
Connectivity check leaks are really not that
That’s why it said “certain” content. Still works with most free TV services who mostly implement those checks for legal reason but don’t care that much.
It didn’t say apps though. On Desktop Linux, apps could see your real IP w/ Proton VPN.
Yeah some platforms are just too leaky if we are being honest, I see no difference between recommending VPN apps on iOS, Linux and MacOS and recommending VPN clients with “supposedly” leaky implementations (proton).
I mean, Apple products are the primary places where this is a problem. Even on Linux, you can obviously set it up with WireGuard via CLI with killswitch. This way works best. I think even the Mullvad client ensures of this properly on Linux. But yes, other clients can be iffy with it on Linux.
I do want VPNs recommended but there should be highlighted notes explaining the issues of the VPN effectiveness on those select devices where issues exist - sometimes the fault of the VPN client/service provider and sometimes the fault of the OS/device maker itself, wherever applicable.
Addendums is likely the best way to go.
Can you elaborate on this? Are you implying that iVPN and Mullvad don’t have true kill switches on linux? If so the Mullvad website seems to contradict this since they don’t have warnings like they do for macOS for lockdown mode
I should have been clearer. Mullvad (and probably iVPN too, but I use Mullvad and Proton) does have a kill switch that works at a moment in time. But there are obscure issues that happen due to Linux network stack being what it is.
There are 3 main sources from where IP leak regressions can happen:
It is impossible to keep up with every kernel commit, and understand if it affects how the network stack operates. This means VPN providers are always lacking behind unless someone discovers a regression.
If Linux offered a single interface for VPNs (and made maintaining it an obligation for stable ABI and release of kernel) to define all network flow (which Android attempts to do, but not perfectly) and disallowed applications from handling their own networking requiring them to use platform tools, it would mitigate a lot of this.
So the only way to be a 100% sure of no leaks, at least on Linux, is to run the operation on a VM/Whonix approach. You can even have fine control over outgoing network and filter for UDP, TCP, multicast, mDNS, or whatever else.