Mac VPN On Demand: what does an SSID match actually prove?
An SSID match is a rule condition, not evidence of trust. Build the On Demand rule, choose the unknown-network default, and keep blocking separate.
Connecting the VPN everywhere except the office Wi-Fi sounds like a two-line policy, and the hard part was never recognizing a network name. The hard part is deciding what a matching name is allowed to prove. Any access point can advertise a familiar SSID, and a successful ping to one address proves only that one probe got an answer. Neither observation establishes that the Mac is on an authenticated internal network.
A name is not an identity
An SSID is a label a radio transmits. It is not a key, a certificate or a statement about who owns the hardware, and a venue or a neighbouring office can broadcast the same string without any coordination. Treating the label as an instruction to turn protection off hands the decision to whoever configured the nearest access point.
The ping test fails for a subtler reason: it answers a question about reachability, not about membership. A target that responds might be reachable from anywhere, might be reachable only through the tunnel you are trying to decide about, or might be a captive portal returning something that looks like a reply. Reachability is a useful fact and a poor trust boundary.
How On Demand evaluates a rule set
Apple's On Demand model pairs an action with optional network conditions, and the rules are evaluated in order: the first rule whose conditions all match supplies the action, and the rest are not consulted. That ordering is the policy, which is why a rule appended "just in case" can silently rewrite behaviour that was working.
The SSID condition refers to the current primary connected network, not to every name visible in a scan. That produces three distinct states, and collapsing them into two is the usual configuration mistake:
| State | What the rule sees | What it must not be taken to mean |
|---|---|---|
| No SSID criterion applied | Nothing to compare | That the network is unknown or unsafe |
| Unknown network | Connected, name does not match | That no rule below applies |
| Recognized network | Primary network matches | That the network is trusted |
Configure it where the policy lives
An approved VPN client or a management workflow is where this rule belongs, and different providers expose different subsets of the available controls. A missing option in that panel therefore means the client did not expose it, not that the platform cannot express it.
Automatic activation also needs an authentication arrangement that can complete without a human, such as a certificate or another supported method. A stored one-time code is not that arrangement, and a rule that fires while authentication cannot complete produces a connection attempt that fails quietly in the background.
Two patterns worth writing into the runbook
The first is the copycat name. A conference venue, a hotel or a tenant in the same building advertises the string your rule treats as "inside", and protection switches off in exactly the place you would least want it to. The name did not lie; the rule asked it a question it cannot answer.
The second is the self-defeating probe. A script pings a private address, sees a response through the tunnel, concludes it is already on the internal network and disconnects. The probe then fails, so the script reconnects and repeats, and the tunnel oscillates while every individual step looks correct. Any test whose result depends on the tunnel cannot also decide whether the tunnel should exist.
Decide the default, then enforce separately
The unknown-network case and the wired case need explicit answers rather than an inherited default. If protected traffic must stay blocked while the system is still classifying the network or bringing the tunnel up, that requires a supported enforcement control of its own; an On Demand trigger supplies connection behaviour, not a blocking guarantee.
Written properly, the administrator rule states the approved exception, the evidence that justifies it, and the deliberate fallback when that evidence is absent. Recognizing a Wi-Fi name is legitimate input to that decision. It is not the justification for the decision, and it should never be the only line in the rule.