Mac VPN Stuck on Disconnecting: What Is Actually Running

“Disconnecting” is a state the client reports while it tears a tunnel down, not a verdict that traffic has stopped. On a Mac that teardown runs as a short sequence, and the label changes only after the component that owns the connection reports back. When one step waits on a helper, a plugin, or a policy decision, the label can sit there after the interface is gone, or the tunnel can keep forwarding while the menu still shows it. Treat the text as “teardown in progress, outcome unknown” and work out which half is true.

Two failures look identical from the menu bar and need opposite responses. In one, the tunnel still carries packets and only the display is stale. In the other, the tunnel is gone but a separate policy keeps traffic blocked, which is often deliberate. Routes and DNS state separate them faster than any menu interaction.

What the label is tracking

A VPN client keeps a small state machine, and the menu bar is a projection of it. For a connection managed by macOS itself, that machine sits in the system VPN framework. For an app-managed tunnel, it sits in the app and its privileged helper. The final step of a stop is not closing a socket. It is releasing what made the tunnel work: the utun interface, the routes that pointed at it, the resolver entries the client injected, and any firewall rule or policy that blocked traffic while connected.

Those steps are separate, so a stop can stall on any one of them. A helper that stops answering, a route that a second interface also claims, or a resolver entry another profile owns can all leave the client waiting. The label is a report about the client's own progress, which makes it authoritative about intent and unreliable about the network.

Find the component that owns the connection

For native configurations, scutil --nc list prints the services the system knows about and their status, and scutil --nc status "Work VPN" gives detail for one service. A tunnel held by a third-party app may not appear in that list at all, so an empty result is not evidence that nothing is connected.

When the profile belongs to an app, rely on that app's status view and its documented Disconnect control. Quitting the window is not a stop request if a background helper owns the tunnel; the icon disappears and the helper keeps the interface alive. Apple's VPN settings reference covers the native controls and where managed settings come from.

Read interfaces, routes, and DNS

Three checks answer most of the question without touching the connection. Interpreting them together is what matters, because any one alone is misleading.

scutil --nc list
netstat -rn -f inet | head -20
ifconfig | grep -A 3 '^utun'
scutil --dns | head -30

• utun interface present, default or split route through it, resolver pointing at the provider: the tunnel is still up and the label is stale.
• No utun, ordinary default route, DNS from DHCP, no internet: a disconnected-blocking policy is doing its job.
• No utun, no route, resolver still pointing at the provider: teardown stopped halfway, and DNS is the leftover to clear.

Then send one request to an internal host that should answer only through the tunnel and one to a public host. Reachability separates policy from leftover state without turning the check into a measurement exercise. Save remote work first if the path still responds, and arrange a second way in before you change networking on a machine you administer remotely.

Why broad kills and profile deletion mislead

Process names such as pppd, racoon, and configd belong to particular implementations. Killing them may affect other connections, leaves routes and utun interfaces behind, and gives you no record of which step was stuck. An old process name is also not evidence that it owns the current profile.

Deleting and recreating the profile is a larger change than clearing a stalled transition. It can discard managed settings and local identity material without explaining what failed, and on a supervised Mac it may simply be restored. Keep removal for a configuration that is genuinely obsolete and diagnose the transition instead.

A stop sequence that keeps a trail

The order below leaves the connection's own controls in charge and produces a record if the stall returns. It also keeps you from turning a display problem into a network change.

1. Save remote work, and confirm you can reach the Mac another way if it is remote.
2. Note the client name, version, and profile. Capture a short window with log show --last 5m --predicate 'subsystem == "com.apple.networkextension"'; older releases keep less history, so run it soon after the stall.
3. Use the documented Disconnect control, wait, then repeat the interface and route checks.
4. If the label is stale but the tunnel is down, leave it and let the client refresh rather than forcing processes.
5. If teardown truly stalled, restart the client, then plan a restart of the Mac once work is saved. Managed machines need the administrator's procedure.

After recovery, confirm the ordinary default route and DHCP resolver are back, and that blocked traffic is either restored or still blocked on purpose. Record the profile and client version with the symptom, so the next occurrence starts from evidence instead of a menu bar guess.