edit: resolved 
Kind of laughable they think we get paid by ProtonVPN, where’s my money!
Fyi i don’t even use ProtonVPN or any of their products and everyone knows that.
As the original poster to this thread, I would like to say that I am equally pleased to see that people are taking the issue seriously (although it took a while and I think the first 9 reactions to the post were thumbs down), and equally dismayed to see so many people that have either not read my post in full or that have decided to perform vigorous mental gymnastics to defend what is clearly a deficiency of a service they are subscribed to.
Firstly, I would like make clear that my complaint was not about being a maximalist regarding the rules on recommending VPNs, but rather to ensure that those relying on the recommendation, such as myself previously, are well informed about what to expect when purchasing the given VPN. In the case of ProtonVPN on macOS - you can expect a ‘kill switch’ that leaks your IP in several conditions, most notably when you switch VPN network.
Personally, I think it is a disservice to other VPN providers that have actually made a high level of effort to properly implement their macOS kill switches to just change the overall requirements and sweep ProtonVPN’s failure under the rug. Had I known about this failure I would never have bought ProtonVPN and I am sure many others would feel the same. I feel that I was misled by Privacy Guides and I’m disappointed to see that they clear don’t care.
This thread has become muddled with misinformation and off-topic replies that have ultimately obscured the core issue I originally described, to the point that even moderators don’t seem to understand the issue. Here I will try and re-calibrate:
There is a fundamental difference between occasional leaks due to OS restrictions & quirks and VPN provider negligence. Additionally, I want to highlight transparency and dishonesty, which are both crucial in the privacy space.
OS restrictions & quirks:
No one complains about ProtonVPN, Mullvad, etc. when
- * MacOs updates cause IP leaks
- * Or when android DNS traffic leaks outside of the VPN tunnel
-
Insert dozens of other examples
People understand that operating systems can have issues and do not blame the VPN provider - they either take steps to mitigate this or live with it depending on their threat assessment.
These are issues that affect all VPN providers on the given OS. In other words, these are OS issues, not VPN Provider issues. These should and often are made known in the Privacy Guides, as mentioned above. It would be unscrupulous to reject all VPN providers because they offer their VPN on these OSs.
VPN provider negligence:
When an issue does not affect all VPN providers, then we can start to say that it is VPN provider negligence. In the case of ProtonVPN:
- ProtonVPN literally leaks your IP every single time you switch networks.
- ProtonVPN does not block your IP on system boot
These are ProtonVPN issues. Other recommended providers, and likely even VPN providers that have not been recommended, do not suffer from the same problems. This also isn’t an edge case, or a temporary bug they will fix. This issue has been occurring since ProtonVPN launched on MacOS. Every single MacOS user that relied on ProtonVPNs “kill switch” will have had their IP leaked, probably hundreds or thousands of times.
Some people are responding as if any leak ever on any OS at all is equivalent to this issue, or even falsely claiming it is a macOs issue when Mullvad does not have the issue. To those people - can you not clearly see the distinction??
It is clear to any non-biased party that ProtonVPNs “kill switch” issue is entirely caused by an unwillingness to actually do the engineering work to implement a proper kill switch for MacOS. If other VPN providers (Mullvad, IVPN) have done it, then that means it is not an OS limitation.
Transparency and dishonesty:
Rather than being honest about the limitation, ProtonVPN directly lies, and claims that their MacOS “kill switch” actually protects you when switching between VPN servers. Here is the direct quote from their official support page:
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.
This quote has been on that support page since they launched ProtonVPN on MacOS and there is nowhere on their website or in any communications I could find that contradicts this…
… Other than, of course, my own reddit post made in February 2025 where they claim that you would need their ‘Advanced kill switch’ which is not available on MacOS.
What is especially egregious is that as soon as my reddit post gained traction, they deleted it, and when another post popped up resurfacing the issue, they also deleted it and claimed that they had to remove the posts as it was “misinformation”. Here is their direct quote:
Hi, the post was removed due to misinformation, particularly in your title.
Title was: ProtonVPN constantly leaks my IPProton VPN isn’t leaking your IP, you’re expecting the regular Kill Switch to do something which is not designed to do – namely, prevent you from connecting to the internet even if you manually disconnect from the VPN.
Please consider changing the title of the post to better fit what you’re actually describing in the body of the post, and we’ll be happy to review and re-approve the post.
What further reinforces ProtonVPN’s duplicity is that they boldly display this warning on their kill switch support page:
Important note: As we have reported, Apple’s macOS and iOS operating systems don’t close all existing connections when you connect to a VPN, specifically certain DNS queries from Apple services, even with the kill switch turned on. However, the kill switch will block all non-Apple connections. We’re aware of this issue, and are working towards a possible fix.
This is so egregious! They make known a technical limitation from Apple that would leak your IP to Apple connections (OS issue that impacts all VPN providers) - They even added this caveat “However, the kill switch will block all non-Apple connections.” to reassure users [that sentence was specifically added in April 2025 btw] that this doesn’t affect non-apple connections, yet completely omit that their kill switch will leak your IP to all connections each time you switch networks, they even claim the opposite, as I quoted previously.
I will also take the time to note that they have been “working towards a possible fix” for this OS issue for many many years…
ProtonVPN clearly is aware of these kill switch issues, yet lies about them and suppresses the truth to get more customers, degrading the privacy and security of customers that would have relied on the functionality at risk. This is an extremely concerning behavioral pattern which betrays all user trust.
ProtonVPN markets sophisticated features such as obfuscation and multi-hop, yet it literally leaks your IP when you change server.
My final word on the subject:
Everyone has their own threat level and everyone has to start learning about privacy and security from somewhere. PG recommendations are supposed to be clear and set at a high bar to enable users to acquire services that match their threat level. I find it bizarre that PG requires recommended VPN providers to offer multi-hop support yet seems to be fine with a kill switch implementation that is so poor it leaks your IP each time you switch networks.
I am dismayed that in three months of having posted this, PG couldn’t even add a one line notice to their ProtonVPN recommendation stating this issue exists.
Is it really so difficult to put a note on the recommendation explaining this issue while you figure out how or if you want to restructure that recommendation page?
That to me sounds like a platform issue in regard to not clearing out the routing table.
That very much sounds like a behavioral issue with regard to connections with the state established. Realistically your Apple accounts are not going to be “private” from Apple anyway because if you’re flicking that on and off they’re going to have your real IP at some point.
Its a limitation of the platform.
The only high assurance way to ensure a kill switch is with separate physical router, or VM like what Whonix does where packets are forwarded from one interface to another and the firewall rules dictate that it must stop if the interface is down.
Submitted to @team for approval:
In particular, as noted by @Overall-Bet3743, both these highlighted statements from Proton appear to be incorrect in my testing:
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.
Important note: As we have reported, Apple’s macOS and iOS operating systems don’t close all existing connections when you connect to a VPN, specifically certain DNS queries from Apple services, even with the kill switch turned on. However, the kill switch will block all non-Apple connections. We’re aware of this issue, and are working towards a possible fix.
There’s 200+ replies in this thread. Which replies did you miss to arrive at this conclusion?
If that’s the “only high assurance way” to “hide your traffic from ISPs” and VPN clients cannot guarantee that, why does PG market public VPNs as such, then?
Hm. How do you reckon VPNs even work on other *nix OSes, if not similar to this?
Whoever this “we” is has been ruling the roost with an iron fist.
I think at this point it is clear that if PG wants to keep claiming to be “community driven” then there needs to annual elections.
After all the discussion about criteria, I certainly did not anticipate that Proton’s failure to meet marketing minimums would be the reason for initiating its removal.
I do wish @jonah would expand a bit more on the decision to leave Proton up for so long after issues had been posted.
Just cc’ing @Proton_Team
Maybe they’ll do something about it now..
Then why is it a minimum requirement on your site? After all, you made it very clear that the community has no say in anything.
You easily could have just removed the requirement for apps to have functional kill switches if this is the position of the people who actually make decisions around here
I think given the handling of this thread by staff I have to agree, even if it did end up with the outcome I was personally looking for the process and near closure of this thread based on falsehoods clearly was not even remotely community driven.
As a reminder, Privacy Guides website editors are a completely volunteer team, and we are not providing you with an SLA that demands we submit PRs within 24 hours of a forum thread being opened or anything like that. I would encourage more community members to volunteer if they want to help improve the site 
There’s also a lot of spam in this thread. I’m not reading 272 replies.
VPN’s don’t provide high assurance and certainly not software apps running on the client. I certainly would not stake my personal security on the integrity of any of these apps from any VPN provider.
They work as much as some application you run after them is likely to be secured but I would never expect them to work correctly for connections from the OS to the vendor, eg to Microsoft on Windows, or Apple on Apple platforms.
These apps likely have similar issues on other platforms. It works but it’s a lot easier to ensure connections are protected when forwarding from one interface to another or dropping packets if the interface is down.
This thread has been brigaded from the people over at /r/privacy so consensus doesn’t really mean a lot.
It is worth noting that ProtonVPN out of all 3 of the currently listed VPN providers is the only one which supports port forwarding which may be of interest to various people who need that.
Dude, please put a minimum level of effort into reading my original post and reply. I was using this example
Important note: As we have reported, Apple’s macOS and iOS operating systems don’t close all existing connections when you connect to a VPN, specifically certain DNS queries from Apple services, even with the kill switch turned on. However, the kill switch will block all non-Apple connections. We’re aware of this issue, and are working towards a possible fix.
to show that ProtonVPN is warning users about OS level kill switch limitation on macOS yet are actively lying about the ability of their kill switch to block connections between server switches.
I’m not sure how to make this clearer to you - the issue my post describes has nothing to do with OS limitations, it is a separate issue in the ProtonVPN macOS client.
Could we atleast get an SLA of less then 6 weeks for staff to atleast respond to a tool suggestion thread? It should be a bit embarrassing that the community had to annoy staff into taking action.
…about 3 months after the creation of the thread and a consensus had already been reached. I think maybe 3 votes have been added since that reddit post.
At the very least you could have scrolled through the top replies before trying to shut down the thread.
Sure, what is your budget?
And over 100 unreasonable posts since my last reply a day ago. I’m not sure what people expect here.
That is what should be done in my opinion as none of these kill switches can be truly relied upon on any platforms as there have been issues on Android and other platforms and not even specific to ProtonVPN.
It’s worth noting that ProtonVPN is the only provider that supports port forwarding with natpmp. This is useful for some purposes, especially if you’re a BitTorrent user on a torrent with very few seeders or maybe only a couple (or one), and you don’t want to have your IP address appear on https://iknowwhatyoudownload.com
I only use a VPN on OPNsense, with policy routing, because I know that VPN software is dog shit. If it’s on my server then I’ll use a docker container like docker-wireguard, because again it can ensure any connected container is protected.
The only real place where I have occasionally used an app is on GrapheneOS on my phone, which to my knowledge is the only platform which actually works properly in regard to the kill switch.
This has already been debunked above. Proton doesn’t use the best APIs essentially. Please see above. comment
They have been tagged twice and I even contacted them in PG dms.
This is totally irrelevant. While a good feature, it isn’t a requirement as is kill switch.
Linux doesn’t have this issue.
BTW, thanks Jonah for the PR.
I missed that post, 187 of 280 thanks for pointing it out. What is unclear is if there were specific technical reasons why they chose not to use pf and instead use Network Extension. Perhaps it has something to do with: TN3165: Packet Filter is not API | Apple Developer Documentation which expressly tells VPN provider to use it instead.
Maybe pf will disappear in future versions of MacOS who knows, then we can remove all the VPN providers because they’ll have to use Network Extension.
Moving off packet filter
If you’re currently shipping a product based on PF, plan to migrate it to a supported API. In most cases that means creating a Network Extension provider:
- If your product is a VPN, create either a packet tunnel or app proxy provider.
- If your product looks at, and potentially blocks, TCP connections or UDP flows, create a content filter provider.
- If your product looks at, and potentially blocks, network packets, create a packet filter provider.
- If your product wants to intercept DNS queries, create a DNS proxy provider.
- If none of these providers meet your specific needs, create a transparent proxy provider.
For information about packaging and OS version constraints, see TN3134: Network Extension provider deployment.
If your product needs to do something that’s not covered by one of these providers, use Feedback Assistant to let us know what’s missing.
This isn’t as hard as you all (PGs) are making it. If things change in the future then that’s a diffrent landscape. At any time Proton could have clarified if things were changing soon and that was the reason for the refusing to fix a known bug. They haven’t in months, and us guessing they might, and that might be their reasoning, and that might make it ok, is wierd and unecessary. I feel like PGs is losing a huge amount of creibility over this issue for no good reason. It doesn’t work as advertised, it doesn’t work when others do, and Proton have demonstrably not been straight about it…
Not really, and removing it would make us lose more credibility, what we should be doing as a community is finding out exactly what is causing this with Network Extensions, and then not reporting it to the marketing department (which the proton account on here is). (The reason we allow these accounts is because its better for them to operate under a banner than as sock puppets under random names, which applies to every company).
I have found in the past working with proton developers directly does sometimes happen, but you have to show through support channels you have a reasonable amount of technical capability as to not waste their time. Unfortunately I neither have Apple products or am a Proton customer so yeah.
I haven’t really seen proper documentation besides some basic curl requests, and a lot of arguing without actually pinpointing the issue. Whether this remains a proton issue, or an implementation issue of Network Extensions is unclear. Either way Proton did do the right thing by not using pf as Apple has made clear in no uncertain terms that is not going to exist in the future. While they haven’t slated a date for it’s removal it’s pretty obvious when they start talking about what they see are the problems with it, that that’s exactly what they intend to do. It’s also worth noting pf has other issues which are quite well known.
No software is perfect and that’s the world we live in.