macOS VPN problems: extensions, profiles and permissions

macOS VPN faults are rarely network faults. The tunnel machinery belongs to the system, and an app only asks for it, so most failures are a permission that was never granted rather than a packet that never arrived. The symptom is distinctive: the app runs, the interface responds, and connecting does nothing at all.

Fault one: the system extension was never approved

Apps that implement a tunnel install a system extension. macOS blocks it on first run and shows a notification, which is easy to dismiss without reading.

Go to System Settings → Privacy & Security, scroll to the bottom, and look for a message about a blocked system software from the vendor. Allow it. On Apple silicon this can require a restart, and on some releases a reboot into Recovery to lower the security policy — which is a decision worth taking seriously rather than clicking through.

Until that is granted, the app cannot create a tunnel. It usually cannot tell you so either, which is why this accounts for most first-run failures.

Fault two: a leftover configuration from a previous client

VPN configurations live in the system's network preferences, not in the app. Dragging an old client to the bin leaves its configuration behind, and two clients fighting over configurations produces connections that start and immediately drop.

System Settings → Network → VPN lists everything. Remove entries belonging to software you no longer have.

Then check for orphaned extensions:

systemextensionsctl list

Anything listed against a vendor you have uninstalled is a leftover.

Fault three: the launch daemon is blocked

Most clients install a privileged helper that runs as a launch daemon, because creating network interfaces needs privileges the app does not have.

System Settings → General → Login Items & Extensions shows background items, and macOS lets you disable them individually. A disabled helper means the app runs and the tunnel never comes up.

If the daemon is missing rather than disabled, look in /Library/LaunchDaemons for a plist matching the vendor. A reinstall is the reliable fix.

Fault four: a stale configuration profile

If a .mobileconfig profile was ever installed — from a workplace, a university, or an older VPN setup — it may still be present and may still be setting network configuration.

System Settings → Privacy & Security → Profiles shows them. If that section does not appear, there are none, which is the normal state on a personal Mac.

Profiles installed by a workplace cannot always be removed by you, and if one is enforcing an always-on VPN or a proxy, that is a helpdesk conversation rather than a troubleshooting step.

Fault five: DNS that did not change

A tunnel that comes up while name resolution keeps going to the old resolver is usually a client that failed to update the service order. macOS resolves through the highest-priority active service.

scutil --dns | head -30

The first resolver #1 block should list the tunnel's DNS servers while connected. If it lists your router, the client did not set them.

Flushing the cache is worth trying before anything more drastic:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Fault six: sleep and the tunnel that does not return

A MacBook that sleeps drops the tunnel, and not every client reconnects reliably. The failure is quiet: the machine wakes, the network works, and the tunnel is down.

Turn on the client's reconnect-on-wake setting if it has one, and its kill switch regardless. Without the kill switch, the window between waking and reconnecting is traffic sent in the clear.

Removing a client cleanly

In order, because doing it out of order leaves pieces behind:

1. Use the app's own uninstaller if it has one.
2. Remove the configuration in System Settings → Network → VPN.
3. Check systemextensionsctl list for a leftover extension.
4. Check Login Items & Extensions for a background item.
5. Check /Library/LaunchDaemons for an orphaned plist.
6. Then delete the application.

Confirming a healthy state

With the tunnel up, what is my IP should show the server's address in the country you picked, and scutil --dns should show the tunnel's resolvers first. Those two checks together separate "connected" from "actually carrying traffic", which on macOS are more often different than people expect.