Your Mac Reconnects the VPN by Itself: Check On Demand

You disconnect the VPN and thirty seconds later the menu bar icon is back. Nothing is haunted: macOS On Demand rules start a connection when the network changes or when something asks for a name the rule covers, and the rule can live in a profile you never wrote. Working through the checks below in order is faster than reinstalling the client. The rule is a policy, so read the policy before you fight it.

What the rule actually watches

On Demand has two decision points: the network the Mac is attached to, and a domain that something is trying to resolve. Either can bring the tunnel up, which is why looking up an internal name starts a VPN nobody opened. The deployment also needs authentication that works without a person present, which is why certificate-based arrangements dominate managed fleets.

A per-application reconnect option can exist alongside the system policy, so the first question is which mechanism reconnected the tunnel. Check the system policy first, then the client, and only then whoever clicked Disconnect. Most client preferences that look responsible turn out not to be. That ordering matters because the system policy wins by default, and a client-level setting can only explain the cases the policy does not cover.

Who owns the policy, and what removal costs

Read the installed profile and the supported client controls before changing either. If the Mac is managed, the conditions are documented somewhere, and asking for that document beats reverse-engineering SSIDs and domains from the outside.

Trust material on the Mac is shared with every other service that uses it, so revocation is the last step rather than the first. Remove the profile that owns the rule, then confirm the rule stops firing before you touch a certificate. A half-removed profile is exactly why people conclude the behaviour is random. The two commands that show what is installed are worth keeping:

profiles show -type configuration
scutil --nc list

What reconnecting does not prove

Reconnecting on demand says nothing about the gap: while the tunnel is coming up, traffic can still leave through the physical interface unless a separate policy holds it. Blocking before the tunnel exists is a different setting from starting the tunnel. A machine that reconnects promptly can still leak during the first seconds.

Route scope is a third question, because a rule that starts the tunnel says nothing about which prefixes it carries. Confirm what the connection routes instead of assuming a reconnect means full coverage. Test it deliberately: quit the client, confirm the service is stopped, then request the resource the rule is meant to protect.

Record the trigger, not the icon

Write down what brought the tunnel up: joining a network, opening an application, resolving a private name, waking from sleep. Notice when it happens rather than only that it happened, because the sequence is the evidence. A specific trigger is worth more than a screenshot of the icon.

Then verify the resource after the connection comes up. The menu bar proves that a service is running, not that the destination you need is reachable through it. Those two can diverge for entirely ordinary reasons, including a route that points somewhere else.

When the rule starts the wrong connection

A connection that starts when it should not usually comes from an obsolete profile, a domain condition broader than intended, or two configurations competing for the same network. All three are visible in the installed configuration, and none of them gets clearer by toggling the service.

Bring the trigger, the profile owner and the intended behaviour to whoever manages the policy. Apple On Demand documentation is the shared vocabulary for that conversation, and it is shorter than the argument. Ask for a policy change rather than a removal, and both sides keep a working setup.