VPN Not Working on Mac after macOS 26 Tahoe? Extensions, Removed Algorithms and a DNS Bug (2026)

macOS gives less away than any other platform when a VPN fails. There is no error code, no adapter list, no event log a normal person will find — just a toggle that goes grey again. Almost all of it comes down to three causes, and two of them arrived with macOS 26 Tahoe.

Start here: is the tunnel actually carrying anything?

The menu bar lies more on macOS than elsewhere, because the VPN icon reflects what the app believes rather than what the routing table says. Two commands settle it in ten seconds.

1. 1netstat -rn | grep default — the default route should point at a utun interface while the VPN is up. If it still points at en0, packets never entered the tunnel no matter what the icon shows.
2. 2ifconfig | grep -A2 utun — a tunnel interface with an address means the client got as far as building one.
3. 3scutil --dns | head -30 — the first resolver listed is the one macOS will actually use. This is where the Tahoe fault below becomes visible.

The system extension that was never approved

Modern VPN clients on macOS do not install a kernel driver; they register a network system extension, and macOS refuses to load it until you approve it by hand. Miss the prompt — it appears once, briefly, often behind another window — and the app installs, launches, shows its interface and never connects. Nothing tells you why.

1. 1Open System Settings → General → Login Items & Extensions, and look under Network Extensions for the app. The switch must be on.
2. 2Also check System Settings → Privacy & Security; a blocked extension leaves an “Allow” button there for a while after the attempt.
3. 3Confirm from the terminal: systemextensionsctl list. The state you want is activated enabled. Anything else — waiting for user, terminated — is the answer.
4. 4If it is stuck, quit the app, remove it, reboot, then reinstall and watch for the prompt deliberately.

macOS 26 removed algorithms your profile may depend on

Tahoe dropped support for several legacy algorithms in the built-in VPN client — the same removal Apple made in iOS 26 at the same time. Configurations built on 3DES, SHA-1 or Diffie-Hellman group 2 no longer negotiate through Apple's own IKEv2 or L2TP/IPsec support.

• The symptom is a connection that tries and gives up, with nothing written anywhere a user would look.
• It cannot be fixed on the Mac. The server has to offer a modern proposal — AES-GCM, SHA-256, group 14 or higher.
• A client app with its own tunnel implementation bypasses Apple's stack entirely and is unaffected. That is the practical workaround when the server is somebody else's.
• The same profile failing on an iPhone at the same time confirms the diagnosis rather than complicating it.

Tahoe's interface ranking, and the DNS leak it produces

This one is genuinely nasty because everything looks correct. macOS keeps a ranked list of network interfaces, and on Tahoe the component that maintains it has been observed re-ranking a healthy tunnel below the physical adapter. The route still exists. Traffic still flows through the tunnel. But name resolution follows the ranking, so queries go out over the ordinary connection while packets go through the VPN.

1. 1Run scutil --dns with the VPN connected. Look at resolver #1: its if_index should belong to the utun interface, not to en0 or en1.
2. 2If a physical interface is ranked first, that is the fault. Disconnect and reconnect the VPN — the ranking is usually rebuilt correctly the second time.
3. 3If it recurs, set the VPN client to handle DNS itself rather than relying on the system to route queries, if it offers the option.
4. 4Verify with an actual leak test rather than by reading settings; the settings will look right.

The general mechanism — why a leak of this kind is invisible from inside the tunnel and what it exposes — is covered in DNS leaks explained. It is worth reading once even if this particular fault never touches you.

Connected, but pages half-load

Small pages fine, large ones stalling, downloads dying at random percentages, SSH freezing on long output. Same signature as everywhere else, same cause: packets too large for the path once tunnel headers are added.

1. 1Find the ceiling: ping -D -s 1400 8.8.8.8, lowering the size until the “message too long” errors stop. Add 28 to the largest that works.
2. 2Read the current value: ifconfig utun0 | grep mtu.
3. 3Set it: sudo ifconfig utun0 mtu 1380. This does not survive a reconnect — if it helps, the durable fix is the setting inside the VPN client.

Note the flag difference from Linux: on macOS ping -D sets don't-fragment and -s takes the payload size. The full reasoning behind the number is in MTU and fragmentation.

Firewalls, content filters and the software you forgot

macOS itself rarely blocks a VPN, but three categories of installed software do it regularly: security suites that terminate TLS to inspect it, corporate management agents that install their own content filter, and ad blockers that operate as a network extension. Two network extensions competing for the same traffic is a real and common failure, and neither will report a conflict.

1. 1systemextensionsctl list — anything of category network beyond your VPN is a candidate.
2. 2Check System Settings → Network → Filters for content filters you did not knowingly install.
3. 3Disable one at a time and retest. Turning everything off at once tells you nothing except that one of them mattered.

Frequently asked