Summary
I think it is good that nobody makes rash decisions.
What exactly makes you think that this is not a Proton specific issue? I have seen nothing to indicate that.
What bug? There are multiple macOS related VPN issues so you’re going to have to be more specific.
And similarly, there is nothing that indicates it is Proton specific.
We do know that Apple has acknowledged a bug which would impact all VPNs.
So summary of the past 70ish posts:
- The community agrees a killswitch is necessary.
- A killswitch apparently doesn’t work on iOS/macOS and apple doesn’t seem to care.
- A killswitch can work on some Linux distros, but it requires manual intervention (please correct me if I’m wrong).
Therefore, if what was said is true, then I would rather have notification stating the above.
I believe ProtonVPN should still be moved down the list of recommended VPNs because of their marketing.
Additionally, I believe it should be mentioned that it is always good OPSEC to close your browser or any apps you don’t want to see your connection switch before switching vpn server as per this.
Lastly, the below should mention IMO as well:
“Doesn’t work” is a bit of an exaggeration for macOS. There are early boot leaks described here, but that’s about it afaik. Based on user reports here and documentation from the various VPN providers, Mullvad and iVPN kill switches are far more robust on macOS than ProtonVPN, which leaks IP addresses during any “disconnect events,” which includes switching servers.
Proton also has an issue on macOS where the VPN can crash unexpectedly and cause your system to reboot on intel based macs as described here. They seem to feel that this issue is Apple’s problem, but I don’t believe Mullvad/iVPN are affected. Either way it doesn’t sound like it impacts the integrity of the kill switch. It’s more of a system stability problem.
A killswitch can work on pretty much any linux distro, but I wouldn’t necessarily recommend attempting it on a distro that is unsupported by the VPN provider unless you know what you’re doing or you don’t feel a robust kill switch is needed for your use case. Mullvad’s lockdown mode only requires flipping a toggle in the app, not sure if that counts as manual intervention. iVPN’s firewall requires some setup in the terminal but they walk you through it on their website. ProtonVPN has a potentially leaky kill switch even on supported linux distros as described here.
I don’t think regular users with low threat models using Mullvad or iVPN need to worry about this, at least on non-iOS platforms, assuming that Mullvad’s lockdown mode or iVPN’s firewall is configured.
It’s been a while since the last time I posted here but here are my 2 cents.
I’m on macOS and have both Mullvad and ProtonVPN, and I did two simple tests:
- Does my IP leak when I switch VPN servers?
- Does my IP leak when my VPN connection is stable?
They are simple because I just used curl and nothing more, and in the commands below en0 is my default network interface while utun6 is the VPN interface.
Mullvad
- Does my IP leak when I switch VPN servers?
% curl --interface en0 https://ifconfig.me
curl: (6) Could not resolve host: ifconfig.me
% curl --interface utun6 https://ifconfig.me
curl: (6) Could not resolve host: ifconfig.me
All good here, Mullvad drops traffic to both interfaces while I’m switching servers.
- Does my IP leak when my VPN connection is stable?
% curl --interface en0 https://ifconfig.me
curl: (7) Failed to connect to ifconfig.me port 443 after 244 ms: Couldn't connect to server
% curl --interface utun6 https://ifconfig.me
xx.xx.xx.xx%
All good here too, all the traffic to the default interface is dropped while the tunnel interface is up. The IP is the VPN IP.
Mullvad passes both tests.
ProtonVPN
- Does my IP leak when I switch VPN servers?
% curl --interface en0 https://ifconfig.me
xx.xx.xx.xx%
% curl --interface utun6 https://ifconfig.me
curl: (45) Couldn't bind to 'utun6'
While the tunnel interface is down the default interface leaks my real IP. It seems like there’s a window after you initiated server switch and before it you’re actually connected to the new server during which you’re leaking your real IP. Note that that window doesn’t start right after you initiated server switch but it starts at some point later.
- Does my IP leak when my VPN connection is stable?
% curl --interface en0 https://ifconfig.me
xx.xx.xx.xx%
% curl --interface utun6 https://ifconfig.me
xx.xx.xx.xx%
While I can use both interfaces, traffic from both seems to go through the VPN server, so no issues here. Although I’d expect the default interface to drop the traffic.
Why Mullvad does not leak traffic while ProtonVPN does?
I think the reason why Mullvad doesn’t leak your IP is they actually use the firewall on macOS (pf) to implement the to drop all traffic that doesn’t go through the VPN interface. This is the right thing to do and I’d expect every serious VPN provider to do this. I’ve also verified this on my machine:
% sudo pfctl -a "*" -s rules
No ALTQ support in kernel
ALTQ related functions disabled
scrub-anchor "com.apple/*" all fragment reassemble
scrub-anchor "mullvad" all fragment reassemble
anchor "*" all {
pfctl: DIOCGETRULES: Invalid argument
}
anchor "mullvad" all {
scrub all fragment reassemble
...
block return out quick proto tcp from any to any port = 53
block return out quick proto udp from any to any port = 53
pass quick on utun6 all flags S/SA keep state
block return out quick all
block drop quick all
}
ProtonVPN, on the other hand, goes the lazy path and just uses the network extension on macOS and hopes Apple will do the right job not leaking your IP address. Network extensions are known for not doing the right job, so ProtonVPN is leaking as the result. We can also confirm ProtonVPN doesn’t touch the firewall:
% sudo pfctl -a "*" -s rules
No ALTQ support in kernel
ALTQ related functions disabled
scrub-anchor "com.apple/*" all fragment reassemble
anchor "*" all {
pfctl: DIOCGETRULES: Invalid argument
}
I believe the reason they leak on Linux might be related to the firewall as well.
On a personal note
I probably understand why Proton does what they do, they’re reusing the iOS implementation where you need to have a network extension and can’t control the firewall, and they don’t want to pour additional effort into the macOS app as it requires time and money to do right. So they just put a note in their docs that the kill switch is buggy on Apple platforms and called it a day.
I contacted Proton about this first time I discovered the issue but I never heard back, so I just moved to Mullvad as they go above and beyond to prevent issues like these. And you can see this in their code.
I also left Proton ecosystem a while ago because I just can’t trust them to protect my privacy online. They cut too many corners in their products and sometimes this leads to privacy erosion like this. If they don’t care enough about protecting my IP then how can I be sure they care enough about the rest?
So I also voted for ProtonVPN removal until they resolve these issues. It’s proved they leak IP on both macOS and Linux. I would be for removal even if their representative comes here and promises to fix both issues as Proton is well known for promising something and not delivering for years.
on iOS/macOS
iOS and MacOS should not be lumped together.
This topic is about ProtonVPN on MacOS. iOS can and should be ignored in this thread, it is off topic and muddying the waters.
Here is what the initial user who reported the problem reported:
When using ProtonVPN on MacOS with the kill switch active, the killswitch failed to provide protection in these 3 common situations:
- During Startup [1]
- When the user intentionally or unintentionally clicks disconnect (from the VPN server) [2]
- When changing servers [3]
#3 is by the most egregious and most serious in my opinion. Switching from one server to another is a situation where users absolutely expect to be protected and other VPNs do offer protection in this scenario. #2 is also a problem, but not quite as bad.
It’s unreasonable to blame a VPN provider for an OS level problem. So if #1 affects all vpn providers on MacOS, Proton should not be blamed for #1. But in the case of #2 and #3, these are common scenarios a killswitch should protect against, which Proton could protect against, but currently doesn’t. There is no evidence #2 & #3 are due to OS limitations, and no evidence has been provided that other VPNs have the same flaws on MacOS.
I suspect we can probably all agree on two things:
- For every OS where killswitch functionality is possible, recommended VPNs should provide a fully functional killswitch.
- For OSes where a fully functional killswitch is not possible, a killswitch should still be provided to the greatest extent that is practical, and limitations should be disclosed and documented.
Mullvad and iVPN currently meet the above criteria afaict. Proton does not, but it is within Proton’s power to fix that, so their removal would be temporary (assuming they have a good-faith interest in offering a functional killswitch).
I personally do not want to see Proton de-listed, but if the alternative is to lower our established standards and bend a criteria specifically for Proton, then I think temporarily de-listing them may be the “least bad option” until they choose to remedy the situation. edit: by far the best solution would be for Proton to just fix the problem 
Privacy Guides is supposed to be for normal people becoming interested in privacy, and this definition of kill switch is not corresponding to that.
I have been using VPNs for more than 10 years and for most people kill switch means: If the VPN server I am connected to goes down or my connection is interrupted for other reasons outside of my control, my IP address is not suddenly exposed to a potential adversary.
The Proton VPN kill switch on macOS does this and it qualifies as a kill switch.
If we take your kill switch definition and think about a normal user, they intentionally disconnect from VPN and now their internet does not work, this is not what they expect. I don’t think kill switch definition should be changed to such an extreme definition that most users do not expect/want. There is no VPN that has its kill switch working like this by default.
If you really have to make a distinction, we can say which VPN has extreme kill switch and label the ones with extreme kill switch. I think most VPN do not build this feature because it is not what most users want.
By the way if you go on the forums, you will find complaints about the kill switches of every VPN, even the Mullvad VPN, and that is why none of them are actually 100% effective, and this is not a Proton specific problem.
A really bad one. If Mullvad can manage to pull off a MacOS client without kill switch leaks, then clearly so can Proton.
Why should we lower the bar just for Proton? If Briar is found to randomly send messages without E2EE in certain situations, do we change the bar for messaging apps to reflect that to keep Briar on? Or do we remove Briar from the recommendations?
It feels bizarre to me that this is even a discussion.
This bar is not making sense. If we ask people what a kill switch is supposed to do, outside of a few extreme people, nobody will say it should kill internet after I intentionally disconnect from VPN. PG must set a bar yes, but an appropriate bar and not an extreme one based on preference of some more extreme people.
It does not mean this bar cannot also exist, but label it separately as extreme kill switch. Nobody would oppose it. Removing a good VPN because it decided not to cater to this extreme preference on a particular operating system is disproportinate and I am not the only one who opposes this.
The absolute last thing PG should do is re-define what a kill switch is just to make sure Proton is reccomended.
That’s not what’s happened here. A few extremists have changed what kill switch means to something unrecognizable, and used that to disqualify any VPN that doesn’t agree with that definition. I suggest a new thread to debate what kill switch means and find consensus, this is the wrong place to debate it.
This is false. The only good faith reason people want Proton removed is that it does not meet the current criteria.
What is really happening is you have a false definition of what a kill switch is and its lead you to believe that the consensus definition is “extreme”.
I am happy to have this debate but it needs its own thread to reach a consensus as it is a different topic.
No thanks. I am not interested in the slightest in re-litigating consensus terms. I have seen that episode.
Please note that our regular kill switch feature can’t protect you if you intentionally disconnect from a VPN server. However, the feature does protect you while switching servers with Proton VPN.
When even Proton themselves add a disclaimer to the kill switch, it means they also think a kill switch should not behave this way, otherwise they would not add a disclaimer.
Edit: Replied to the wrong post… @6sxbi was who I meant… 
I think that’s the wrong take on this. Proton discovered the bug in Apple so they point out the Apple bug. They call the feature as implemented a kill switch so they consider it to be a kill switch.
Before we can even discuss disqualifying Proton for not having a kill switch (which is not true in the opinion of many), there must first be an agreement on what is a kill switch.
Because it might not work on Apple systems, does that mean they shouldn’t care about other systems where it works because other providers show that it is possible?
It isn’t even an Apple only disclaimer….
Did you read the link you post? The disclaimer is Apple only. They also offer what they call advance kill switch on non-Apple platforms, which is what I call extreme kill switch. This should not be the default kill switch definition. Even mullvad calls this lockdown mode instead of kill switch, so mullvad also does not consider this to be standard kill switch.
Proton itself offers a definition for ‘kill switch’ in the article @any1 linked as:
… a security feature that protects your IP address in case you unexpectedly lose the connection to a Proton VPN server. In case the connection is interrupted, a kill switch blocks all external network traffic to and from your device until the connection is automatically re-established to the same VPN server…
They refer to this feature as a “regular kill switch” elsewhere in the article, opposed to a separate feature they call an “advanced kill switch” (also referred to as a “permanent kill switch” under their Android section):
Our Windows and Linux (GUI) apps also feature an advanced kill switch. In addition to protecting you from accidental VPN disconnections, this prevents you from accidentally using the internet without the VPN turned on, and it will persist when you shut down and restart your device. You will not be able to connect to the internet if you manually disconnect the VPN without also disabling the advanced kill switch
Edit: whoops, duplication of efforts, lmao