Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Privacy concerns with Silicon Macs
- Thread starter Macintosh101
- Start date
- Sort by reaction score
Claims about Apple apps bypassing VPN on Big Sur are false. See this: https://news.ycombinator.com/item?id=25113039
Yup, Mullvad released a report about this as well .. it doesn't bypass their VPN.
Big no on Big Sur: Mullvad disallows Apple apps to bypass firewall
Despite Apple’s changes to macOS with the release of Big Sur, we can confirm that the Mullvad app still performs as intended by not allowing Apple’s own apps to bypass our VPN firewall.
Apple didn't make a mistake here, there are plenty of reports coming in that are not sensationalist garbage that show VPNs function the way they always have. I posted one from Mullvad.
Not entirely true. Depends on what type of api the vpn/firewall use. So some of them would function while some of them won’t.
More specifically:
- “System-wide” VPNs using NEPacketTunnelProvider with destination IP based routing continue to work as before, including routing Apple application traffic. Most VPNs people are thinking of fall under this category.
- Per-app VPNs (using NEProxyAppProvider) cannot be set up for Apple applications. However, the whole point of per-app VPNs is to allow specific corporate apps to route traffic through a corporate VPN, while allowing other general purpose apps to bypass the VPN in order to prevent the user’s non-work communications from being monitored by the corporate VPN.
- VPNs using custom kernel extensions are no longer supported (without workarounds that disable security measures)
- The classic BSD PF firewall continues to work as before, including restricting the traffic of Apple applications
- Firewalls using custom kernel extensions (like pre-Big Sur versions of Little Snitch) are no longer supported (without workarounds that disable security measures)
- The NEFilterDataProvider API that Little Snitch is forced to use on Big Sur does not allow intercepting the communications of certain whitelisted Apple applications. This is a bad thing, but this is unrelated to VPNs.
Correct but this is not a "mistake" by Apple, which is what I was referring to. Correct me if I am wrong (been wrong most of my life), but developers have had ample time to stop using the KEXT based methods, if they are failing now that's simply due to a problem they created at this point.
The NEFilterDataProvider issue is one that will need to play out over time but I still don't see it as being the end of everything like many folks around here are worried about. While Apple can indeed restrict what they want this can still be blocked by a hardware firewall, one that could still work on public WiFi (pi zero was mentioned before).
Like I said though, I will let time play its part here before getting bent out of shape about anything. My VPN of choice works like a charm, at home I can easily block traffic I do not want going out at my gateway but currently I just don't see the end of all things like some are talking about.
Hardly the end of everything. Just Apple making it harder for the end user to to use VPN in some circumstances without any good reason. Still a bad move from a company advertising itself as a stronghold for the user privacy.
NEFilterDataProvider really has nothing to do with VPNs, and has no impact on VPN users. Also, the behaviour of NEProxyAppProvider is a non-issue, since per-app VPNs are only meant for a specific usecase involving corporate MDM. See this for more info on per-app MDM: https://support.apple.com/en-gb/guide/deployment-reference-ios/apdfbf6f529b/web
Apple deprecating some kernel extension APIs and replacing them with user-space APIs is in principle a good thing, as it minimizes privileged third party code, which generally benefits security. Deprecating some kernel extension APIs does break some VPN applications that used those APIs, but for the most part they can just move to new APIs.
The only bad thing Apple has done is neutering NEFilterDataProvider, not giving Little Snitch a fully capable replacement for its kernel extension. By excluding Apple applications from NEFilterDataProvider, it allows malicious applications to smuggle data around Little Snitch using Apple applications.
There's a difference between how something is ment to be used and how it's actually used. To me this doesn't look like an engineering decision.
Per-app VPN has always only worked with corporate MDM. Also, preventing corporate per-app VPNs from routing traffic from non-corporate apps (such as built in Apple apps) is beneficial for user privacy, since it prevents employers from unnecessarily snooping on personal traffic.
I hope you are right. And it will be good for everyone if Apple come to their senses and fix NEFilterDataProvider. Both apis use the same exclusion list which is the reason I think this is simply a political rather than engineering decision.
Disabling per app VPN breaks the split tunnel in PIA VPN on Big Sur: https://www.privateinternetaccess.com/helpdesk/news/posts/split-tunneling-on-macos-11-0
Their issue has nothing to do with per-app VPN. They were never using that API. They had a custom kernel extension that's no longer supported. Split tunneling works fine using the NEPacketTunnelProvider API with destination IP based routing. They just need to update to use the API, and they've had over an year to do that (kernel extensions for that purpose were announced as deprecated in Catalina).
Last edited:
Their split tunnel is not based on destination IP but rather on source app:
Last edited: