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.
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.
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:
https://news.ycombinator.com/newsguidelines.html
Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
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.
https://news.ycombinator.com/item?id=25118136
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.
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 not denying that NEFilterDataProvider is an inferior solution for per-app firewalls like Little Snitch, compared to their previous kernel extension.
> 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.
(emphasis mine)
It looks like a lot of people are under the assumption that enabling VPN means system wide.
More info on the purpose of per-app VPNs: https://support.apple.com/en-us/guide/deployment-reference-i...
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...