This is indeed an interesting discussion. Especially as it would litterally go against what apple says in the same link as above:
Do not use Packet Filter in a software product that you distribute to a wide audience. If you’re currently shipping software that relies on Packet Filter, plan to migrate to Network Extension.
Personally I think it is not a durable solution and therefore not a good idea to recommend. I think we better invest time other solutions to the problem.
I don’t think it does. Apple saying they will not allow something in the App Store is not the same as Apple saying they will remove the feature. If anything, I think it’s more likely that Apple will start enforcing App Store rules on all apps than they would remove PF, although that would ultimately cause the same problem for VPN apps.
So, I suppose even if I disagree with you and dngray that the feature will be removed, I agree it’s not a good idea to recommend. I think we should find the App Store’s distribution rules acceptable on macOS and iOS and not punish developers for following them.
Let me try to frame it a bit differently.
This doc clearly shows Apple wants app developers to move to NE but it also says PF remain legitimate for the following use cases:
- As an implementation detail of various system services built-in to macOS
- As an advanced feature for users, site admins, and so on
So, if you’re a system service or require advanced networking functionality then PF is the way to go. I hope this makes it clear that Apple knows there are legitimate use cases not catered to by NE, so I don’t know where is the “pf is going to be removed” comes from.
Now, kill switches are a very unique use case and NE doesn’t provide any functionality to implement them. includeAllNetworks is not the one based on documentation, observed behavior and past usage patterns.
This is clearly an advanced feature Apple is talking about in their TN (as we want to prevent any traffic headed outside the VPN network interface), so PF is the right tool for this job just like on other systems.
Now we’re in the following situation:
I see two solutions to this situation:
I don’t see any practical difference between those two options and how the firewall is managed. There’s clearly no difference for PF who feeded it the ruleset.
Although I’m happy to hear why we’d think that VPN clients shouldn’t implement a proper kill switch just because Apple prefer only users (and the system) to manipulate the firewall.
I think this is an important point, and the reason I would emphasize that I don’t think PF is going to be removed from macOS, even if apps shouldn’t use it, because I wonder if we should give instructions on how to set up a kill switch with PF on macOS?
I am not sure what those instructions would be though, unfortunately I’m not familiar with pfctl.
Mac App Store is a highly restricted environment, and Apple prohibit apps from doing a lot of useful things because of the sandbox. Not to mention it’s not free to ship there.
I’d imaging it might be too restrictive for some apps and prevent them from offering what they can offer outside MAS. Why would you prefer it instead of a client distributed outside of MAS?
I wouldn’t, but I don’t think we should categorically disallow MAS VPN apps either.
Fair enough although those VPN clients would be restricted to Network Extensions only, so no kill switch.
I wonder if we should give instructions on how to set up a kill switch with PF on macOS?
I don’t see a functional difference between a vendor kill switch and a DIY kill switch. I do see other differences though, and the obvious one is you can’t expect users to correctly block the traffic on their own. They can’t test it works, they don’t know when it doesn’t work, they can’t maintain it and they probably won’t bother as the UX is horrible.
A proper VPN client just makes it work and it does everything it can to prevent leaks. Mullvad does this with their talpid framework, they do audits, they document edge cases, and they have an infrastructure for testing it. I don’t think you can expect user to do better than this.
Authoritarian countries are heavily censoring App Store. I can imagine Mac store also being censored.
On Android, another VPN app cannot break the kill switch because of the VPN slot exclusivity. With firewall rules, any tunneling app breaks the routing table or introduces uncertainty otherwise. Vendored kill switch, however flawed it might be, does indeed guarantee something. At least on GrapheneOS. It’s been 3 years since severe leaks were discovered on Android and they’re still unfixed 
With Mullvad’s approach to killswitches, it wouldn’t make sense for them to maintain their own solution if Apple would’ve provided an adequate solution, but they have to.
On Android, Mullvad doesn’t want to add LAN routing functionality while the kill switch is active, stating that an app shouldn’t be made into a router and that firewall rules are the only proper solution in their view. I don’t have an opinion on this topic, but we should at the very least recognize that Proton put a bet on Apple and were waiting for them to do something.
I used to have a strong opinion on this, i didn’t want Proton to be punished, but i’m not sure about this anymore. On desktop OSes, there’s no “native“ or proper solution to solving things.
Indeed, this is my biggest problem with a strict kill switch criteria.
Documentation for includeAllNetworks is clear on what kinds of traffic will be not sent to the VPN app.
Mullvad’s blog post is concerned with other bugs related to includeAllNetworks, not any perceived leaks.
Mjtsai’s blog is how things are in heavily sandboxed worlds of iOS and Android (where the OEM / 1p apps run with higher privileges and call the shots).
Discounting “Always-on VPN” (available only on ‘supervised devices’ , not sure why you qualify Network Extensions as having ‘no killswitch’ when it in fact, within the boundaries acceptable to Apple for iOS, includeAllNetworks is exactly that? If VPN apps won’t use this killswitch, then Network Extensions will provide even worse guarantees with respect to leaks. The leaks that do happen due bugs with includeAllNetworks is for Apple to fix.
From a quick glance at the code repo, the official WireGuard client for Apple devices doesn’t seem to use includeAllNetworks, so it’ll be strictly worse than apps that do, no matter what else it might be doing to prevent leaks.
I think the crux of the issue is that includeAllNetworks simply does not appear to cover the case where you disconnect from the VPN in order to connect to a different server, when it probably should. This is what most people would consider normal kill switch behavior that I believe Apple doesn’t provide any functionality for Network Extensions to implement.
Gotcha. Without the includeAllNetworks flag, any 3p app can bypass the VPN on iOS / macOS at will. With that flag, 3p apps would be able to bypass only in those specific scenarios that trigger Apple’s implementation bugs. Two very different things.
Similar points were made across multiple threads in multiple replies… here’s one:
I agree, but I’m not sure I know what you’re proposing we do here?
As it often is unfortunately when people start replying because they want their opinion to be the right one, often there isn’t much research. One thing in the entire time we learned of running Privacy Guides and it’s predecessor is that not all opinions are equal, that is just a fact. Some people simply know more than others in an area or have done more learning about the nuance to begin with.
That is why we don’t generally decide on things based on “vote” or “consensus” because fundamentally it often comes down to fact.
Nobody can know for certain what Apple’s internal plans are but, from the wording it’s pretty clear they do not like the state of pf (and it has other known issues that they have not fixed). When this is usually the case in anything it often is because its not a focus and is deprecated.
The fact it never existed in iOS in the first place (no way to control pftctl), is a pretty good indicator.
They also say for not wide-spread app distribution which a VPN app certainly is, so no.
I think we really should focus on achieving this at a router level, because it’s how you avoid all the leaks because of various quirks. It should also be noted that Apple does have certain exclusions for Apple related domains in regard to NE and this is on purpose.
For example if you consider this article VPN overview for Apple device deployment - Apple Support (CA) they state that various things will not work (eg Apple Watch) if you’re on a VPN.
The way Apple sees it, you shouldn’t be trying to push everything into the VPN and it should be a per-app situation.
The reason for that is, if it were a company VPN with a BYOD - likely one of the most common use cases then you wouldn’t want data that goes to Apple related to your own personal Apple account going through your employer’s servers.
please also mind that the way Mullvad approaches the issue is not robust either as it is not a supported method. Mullvad is pretty open about that. macOS sometimes leaks traffic after system updates
As long as the platform does not offer a good supported solution, there won’t be a good way of doing it.
Is that still true after 2 years? That Mullvad post is from 2024.
I guess best to always update manually and turning off WiFi after download or before installation begins.
Quite likely, or there’s some other case which it can happen.
I think there’s a disconnect with the community in how unreliable these “kill switches” generally are - that may even be because of VPN marketing in the first place. A lot of people see these apps and see the glossy interface and think everything is perfect.
When you actually start looking at the source code, it’s far from that, and in a lot of cases it has to be over engineered in order to try to be best case, certainly more so than a VPN router.
I am no expert and neither am I saying that I am necessarily right and please do correct me if I am wrong, but even if the protection that Mullvad and IVPN aren‘t leaking the IP address on macOS when switching VPN locations comes from an officially not supported, hacky workaround, still, doesn‘t that mean that if it is stable and works constantly (which is the case apparently) that Mullvad and IVPN are doing everything to prevent these leaks and Proton VPN does not do that, doesn‘t that mean that it should still be removed as we end up in this situation?