Leaky macOS VPN After System Update
We have found that you could be leaking traffic on macOS after system updates. To our current knowledge a reboot resolves it. We are currently investigating this and will follow up with more information.
In this scenario the macOS firewall does not seem to function correctly and is disregarding firewall rules. Most traffic will still go inside the VPN tunnel since the routing table specifies that it should. Unfortunately apps are not required to respect the routing table and can send traffic outside the tunnel if they try to. Some examples of apps that do this are Apple’s own apps and services since macOS 14.6, up until a recent 15.1 beta.
Previously:
- Networking Issues in Sequoia
- Local Network Privacy on Sequoia
- macOS Firewall Regressions in Sequoia
- iOS VPNs Are Broken
- Apple Apps Exempt From Network Filters and VPNs
5 Comments RSS · Twitter · Mastodon
This sort of thing is partly why I wish developers, especially for security apps like VPNs and firewalls, could still viably use kernel extensions rather than the new system extension API. Because with the latter you are forced to deal with Apple's multitude of bugs and omissions, and you're not truly in control. For whatever their faults may have been, with kexts you were at least in control of everything and how you patched macOS.
Is it just me or is it always best practice to manually reboot iOS and Mac devices after the automatic reboot for the update?
For example RCS quit working for me on 18.1 RC until a reboot.
There just seem to be lots of little post update bugs that require a reboot to reset them properly.
@Bri I get what you mean but it doesn’t substantially change things. Before, Apple’s bugs might have caused the whole system to crash. Now at least the damage is limited.
It wouldn't be so bad if Apple provided user-facing tools (maybe CLI) for exercising this stuff; then we could at least troubleshoot and diagnose it. But no, the only interface is an API, accessible through some barely-documented framework, so Apple has almost no real incentive to make it work properly and very effectively shifts burden/blame onto third parties for something that's beyond their control.
And kexts were the way you got around Apple's stupid self-imposed limitations. For instance, you could have a tap device for implementing a layer 2 VPN that didn't discriminate against "local" network services. And your VPN would correctly capture all the traffic, etc. If Apple are going to replace them with an API, that API has to work.
@Bart That's not really the issue, because with kexts it was third party developers who might cause the whole system to crash. Apple doesn't dogfood their own extensions API.
Also, in the earlier days of OS X (though not the earliest -- I'm talking circa 10.4 and later) kernel panics rarely if ever happened. Even with Apple and various devs mucking about in the kernel, everything was robust and stable.
So I always felt like System Extensions were a solution to a problem no one had. Kexts had been working great. There was no need to replace them.
...Well, there was one problem with them. It gave users and devs control over their own system. Modern day Apple absolutely abhors such a thing!
