TL;DR
I did some experiments to determine, whether macOS Big Sur is able to bypass VPNs as claimed a lot right now. The answer is: It is not. Packets do, what the routing table says they should do.
Introduction: A lot of posts in the past claimed, that the new macOS Big Sur would be able to bypass VPNs for Apple’s own products. The most famous ones were Your Computer Isn’t Yours and Apple apps on macOS Big Sur bypass firewall and VPN connections. Can be used by a Malware..
Well, I couldn’t understand how this could even work in theory and none of the people spreading the FUD did explain anything, so I created a test setup. My MacbookPro Late 2016 with Big Sur was connected via Ethernet to another PC with two NICs, running Debian Buster. The two NICs were bridged together and the second one was connected to my LAN in such a way, that the MB could access the internet (both via IPv4 and IPv6) without any packet being dropped. Wifi und Bluetooth were both switched off.
I ran tcpdump on the bridge and captured every single ethernet frame that was spit out by the MB. Additionally I ran Wireshark on the MB in order to check, whether the kernel might hide some ethernet frame from Wireshark. Such a frame would still be visible on the bridge.
On my MB I created a VPN tunnel to yet another machine on my LAN and tested all three major VPN implementations: IPSec (Cisco Anyconnect), OpenVPN and Wireguard. All VPNs were first set up to route all traffic through the VPN, and afterwards as a split tunnel, with Apple’s IPs routed through the tunnel.
Furthermore, I separately captured any single ethernet frame on the bridge, which did not use the VPN tunnel.
I conducted this experiment for 48 hours, used Apple’s own apps, installed some from the App Store and otherwise did just work on my MB.
Result: The only traffic not routed through the VPN were: DHCP, ARP and IPv6 Neighbor/Router-Advertisement/Solicitation. That’s it. There was not a single packet that did not follow the rules in the MB’s routing table and thus did not use the VPN tunnel.
Note, that the MB could have easily accessed the public internet by simply using the data provided by DHCP! In the MB’s routing table the default gateway is not replaced when connecting to a VPN. Instead, a new entry is pushed on row above it and simply gets precedence this way. Thus, the MB had all information that was necessary to completely bypass the VPN and still no packet did this.
Furthermore, there was not a single ethernet frame captured on the bridge, which was not also captured in Wireguard, so the kernel does not bypass Wireguard as well.
Debunking Your Computer Isn’t Yours: About Jeffrey Paul’s claims about bypassing VPNs (see this comment): Jeffrey Paul wrote:
The version of macOS that was released today, 11.0, also known as Big Sur, has new APIs that prevent Little Snitch from working the same way. The new APIs don’t permit Little Snitch to inspect or block any OS level processes. Additionally, the new rules in macOS 11 even hobble VPNs so that Apple apps will simply bypass them.
He gives “a source” for his claim, but following the link we get some description from some author called Sami about Little Snitch and then:
If it isn’t patched, then it seems to be a deliberate move by Apple to not allow its own apps to bypass through VPN and firewall connections.
I don’t understand how one can deduce “Apple’s apps will bypass VPNs” from that quote.
What actually happened is, that Apple changed some API for userspace applications that want to sniff on the network traffic, to be precise: NEFilterDataProvider. Apple’s own services are listed on a exclusion list which prevents third party apps from tinkering with it.
I don’t say that’s a good move, but this doesn’t mean it bypasses VPNs, like, not at all. Packets still do what is written in the routing table and if the routing table says “put it in the tun device”, then the packet is put in the tun device. I ask everybody who claims otherwise to provide a reproducable scenario were a setup such as mine described above will show the leak. Otherwise it’s just FUD.
Maybe people who claim that Big Sur bypasses VPNs should properly specify that they don’t mean VPNs, but apps which emulate some VPN-like behavior for another app, i.e. apps which rely on NEFilterDataProvider rather than on a proper tunnel interface.
Update regarding evidence: A few users, among others u/Veei and u/TNastELoopio, have asked for proof. Well, I don’t know what you want to see here. People claim Big Sur bypasses VPNs (presence of packets not routed via the tunnel), I tried to verify that and couldn’t (no such packet observed).
Do you want me to upload the packet captures? I won’t do that simply for privacy alone, but even if I did, then you’ll claim I manipulated them and removed the leaking packets, no? Please tell me, how I have to set up an experiment and which data I have to post online, such that you believe in the result, even if that result does contradict your expectation.
I ask a counter question: Where is Jeffrey Paul’s proof? Where is the uncut youtube video where he shows how he sets up a Mac with Big Sur and a - say - IPSec VPN to some endpoint outside his network, configured to route all traffic via the tunnel – and where he then shows a live packet capture on his gateway, showing packets which don’t use the tunnel?
The people who claim that Big Sur bypasses VPNs need only a single such packet to show they’re right, while I have to prove the absence of such a packet no matter what, which is simply impossible.
You demand something from me which is impossible to obtain, but believe Jeffrey Paul and other bloggers even without any evidence from their side just by their word.
Well, I showed you my setup and how to do that on your own. Now simply repeat it on your own to convice yourself. Macworld did the same and got the same result as I.
Update 2: Some people sent me links to how Patrick Wardle shows the VPN bypassing. Seriously, have you even understood what Patrick is showing in that ten second gif? Because if you think you can see a VPN bypassing there, you have clearly not understood what he’s showing.
There is a reason why Patrick himself does not even talk about VPNs at all.
I think most of the confusion stems from the wrongful use of the term VPN, Virtual Private Network. Apple hobbled apps, which implement user-space firewalls with proxy-functionality and call that a per-app-VPN.
Well, I wouldn’t even consider this a VPN, as there’s no virtual private tunnel involved. Even a SOCKS-Proxy is just called a poor-man’s-VPN, but not a VPN.
Apps which use tunnel interfaces and manipulate the routing table will work just fine. So, if your app says it uses IPSec, OpenVPN or Wireguard, then you’re fine.
If your app advertises military grade encryption on a per-app basis and you don’t see additional routes via netstat -rn and additional tunnel interfaces via ifconfig, then Apple traffic will probably bypass this app. But this is a defect in the app’s design and has nothing to do with VPNs, because the APIs these apps use were never intended to provide a VPN functionality in the first place.
Update 3: A few people suggested I should have installed apps not from the AppStore, but directly from the developer’s websites.
So, I ran the test again, this time capturing packets on the MB, on the Debian bridge, on my VPN gateway and on my normal gateway which the MB would’ve used if not connected to the VPN. The MB could’ve bypassed the VPN via this gateway, if such a method was implemented.
I installed Zoom, Skype and Spotify.
Results: Not a single packet leaked. All of them used the tunnel.
So I started tinkering with the OCSP requests, which are http. First I dropped all http requests at the VPN gateway, afterwards I rejected them via an ICMP admin-prohibited. Still, not a single packet leaked in both cases. All apps could still be installed, however it virtually took an eternity, because the MB still tried to verify it until it gave up.
