Apple apps do bypass NEFilterDataProvider (used by application firewalls like Little Snitch), and the per-app VPN mechanism (using NEAppProxyProvider). Thus, per-app VPNs can't be applied to Apple applications, but per-app VPNs were never intended to globally intercept traffic. Claiming that Apple apps bypass (all) VPNs in Big Sur is deceptive - they only bypass per-app VPNs that were never intended to cover all system traffic in the first place.
Traditional VPNs that cover the whole system and route traffic based on destination IP (such as OpenVPN in UTUN mode) use the Packet Tunnel Provider in Destination IP mode. To the best of my knowledge, global VPNs routing based on destination IP (ie. non per-app VPNs) still route traffic from all applications, including Apple ones.
You are correct. I tested several of the normal ‘whole-system’ VPNs on Big Sur last week when this misleading headline came out and Apple traffic was correctly routed over the VPN in each case. (Both the built-in macOS VPN client and third-party tuns such as Viscosity, etc.)
My testing was not a comprehensive assessment of macOS-compatible VPN services and my selection was biased towards breadth of implementations disregarding all other criteria. It would be inappropriate for me to recommend any of them as I did not assess for quality of app, support, billing, or privacy.
If it adds a default route to your routing table when you connect, it's fine. If it offers fancy per-app traffic rules, it's probably not fine.
Ah, you're right, I missed something. None of my comments explain my testing method. I apologize; this was present in an earlier draft of the initial post and got lost along the way. The question asked was only "Which VPNs did you test?", not "What was your methodology", and I didn't catch the absence of the latter until you asked that in reply.
In summary, for each VPN app, I connected to the VPN and then wiretapped my computer to see if it originated unencrypted network traffic to any Internet destination other than the VPN while operating a variety of core macOS services on the exclusion list, such as Software Update and App Store.
In each case, I was able to witness Apple traffic on the VPN network interface but not on the Ethernet interface below it.
For anyone testing Mullvad, please keep in mind that they make use of the macOS packet firewall layer in addition to the usual VPN network interface, which may complicate my testing procedure if followed stringently as there might not be Apple traffic on any interface, VPN or not, in that scenario. Mullvad context is in another post: https://news.ycombinator.com/item?id=25116863
APPENDIX: Note that, as far as I can determine, existing TCP connections were not reset onto the VPN when it was connected. Since I was inspecting all traffic, not just Apple traffic, I ended up having to restart Slack a couple of times just to get it to switch over to the VPNs. I would imagine this should be studied more closely, since it was a surprise to me.
Their question could be confused by others as it's phrased. "my methods" includes both the VPNs I tested, and how I tested them. They correctly observe that I withheld all information about my methods, rather than only the component I intended to.
Someone else who didn't realize that I'd left out the methodology could possibly interpret their question as confused/misplaced/etc. I definitely wondered about that at first, but I took the good faith approach:
Because we are not owed anything by HN commenters. Floatingatoll posted what they wanted to post, and they have no responsibility to post anything more than that.
If you or I think there should be recommendations of which specific VPNs properly route Mac app traffic, then you or I can do our own tests and post our own comments with those results and recommendations.
I'm definitely frustrated that so many people (in top-level comments on HN, especially) are taking for granted some random Internet post without verifying it, but that's no excuse for the missing methodology.
The problem is per-app firewalls used to be able to block all apps/traffic equally. Apple then deprecated/discouraged the KEXT mechanism these firewalls used in favour of NEFilterDataProvider which, as you described, is clearly an inferior solution.
You can't claim that these apps were not meant to do the very thing they used to do until Apple made such operation effectively impossible.
I'm talking about VPNs, not firewalls. This article (and people in general) are claiming that Apple applications bypass VPNs, and falsely implying that system-wide VPNs are no longer possible in Big Sur. NEAppProxyProvider was never meant for system-wide VPNs. NEPacketTunnelProvider, the system-wide VPN mechanism (when used in destination IP mode), continues to route system-wide VPN traffic, including that of Apple applications.
I'm not denying that NEFilterDataProvider is an inferior solution for per-app firewalls like Little Snitch, compared to their previous kernel extension.
I think you're right, the article definitely oversteps its bounds and ends up claiming that Apple apps can bypass all VPNs and firewalls. The correct summary of the situation is probably the first tweet in the article:
> Some Apple apps bypass some network extensions and VPN Apps. Maps for example can directly access the internet bypassing any NEFilterDataProvider or NEAppProxyProviders you have running
But then the article sloppily goes on to say:
> What Wardle found is that the Mac App Store on the latest macOS bypasses any firewall.
The PF (BSD Packet Filter) firewall built into Mac OS covers apple processes. However, I don't think its interfaces are sufficient to implement the functionality of Little Snitch. The new-ish NEFilterDataProvider API used by Little Snitch on Big Sur is neutered by allowing Apple apps to bypass it.
Per-app VPNs have existed for some time, and their use case is different from system-wide VPNs. Typically, per-app VPNs are used when you want to grant specific applications access to resources on say a corporate VPN, without granting all applications access to the VPN. Per-app VPNs are also useful if you want to protect a specific app's communications through an encrypted tunnel without affecting the rest of the system.
Traditional VPNs that cover the whole system and route traffic based on destination IP (such as OpenVPN in UTUN mode) use the Packet Tunnel Provider in Destination IP mode. To the best of my knowledge, global VPNs routing based on destination IP (ie. non per-app VPNs) still route traffic from all applications, including Apple ones.
See this for more details on the Packet Tunnel Provider: https://developer.apple.com/documentation/networkextension/n...