Mac VPN status: check the profile, the resource, or the flow

Somebody asks whether the VPN is up, and three different people mean three different things by it. An operator means the Office profile finished authenticating. A scheduler means the private API will answer. A security review means this particular request left through the protected path. A script that greps the route table for an interface name answers none of them reliably.

So the checklist starts before any command runs: name the subject of the check. Everything after that is choosing the interface that can actually report it.

Name the subject before the command

Write the question as a predicate with a subject. "Is the Office profile connected" is testable and has an owner who can answer it. "Can this job reach the internal API" is a second predicate with a different failure mode. "Does this request use the protected path" is a third, and it is the only one that talks about a single flow rather than the whole machine.

Mixing them produces automation that lies confidently. A job that checks the profile state and then assumes the API is ready will page somebody at the wrong layer, and a job that pings the API and calls it proof of a tunnel cannot tell a working VPN from a laptop that happens to be on the office network.

One profile: ask the thing that owns it

For a native Mac service, the network connection controls in scutil report exactly this. They read the state of a named configuration rather than inferring anything from an interface.

scutil --nc list
scutil --nc status "Office VPN"

The profile name in that command has to be the real one from the list output, not a guess. This is a read-only path for native services, and it is not a guarantee that a third-party client appears there at all; a provider that manages its own tunnel needs its own supported status interface. Check the list before you write the status call, so a missing name fails visibly instead of silently matching nothing.

Inside a Network Extension app, read the status from the manager and connection objects rather than from the system. Be careful about scope here: loading saved configurations returns only those created by the calling app, so an empty result means "none of mine", not "no VPN on this Mac". Distinguish a failed query from a confirmed disconnected state, and treat the transitional states as their own outcomes instead of retrying a connection that is already coming up.

One job: readiness is a separate predicate

If the question is whether a job can proceed, test the job's actual dependency after the connection owner reports the intended state. A bounded readiness check against the private resource is the right shape: it proves what the job needs and nothing more.

It still cannot prove that every request on the machine uses the tunnel, and it should not be reported as if it could. Equally, a resource that answers over the ordinary network is not evidence of a VPN, which is why the two checks stay separate even when both succeed.

When the job genuinely requires a protected path, that requirement needs the deployment's own enforcement design: routing, split-tunnel exclusions, a firewall rule or an application-level requirement. Availability of an endpoint is a fact about a server. Enforcement is a fact about the client's configuration, and one does not demonstrate the other.

One flow: inspect the chosen route

For a single flow, look at the destination, the address family and the source context with the routing diagnostic that reports the selected path for that specific destination. That output names the interface and the source address actually used, which is a much stronger claim than a default route entry.

Broad browser checks answer a different question entirely. A public IP result describes what one request looked like from one server's point of view, and it says nothing about private DNS, excluded applications, or a second network context that another process is using.

Return a result the caller can use

Choose a return shape that matches the predicate: a named profile state, a resource readiness verdict, or an explicit unknown with the evidence that produced it. Keep the configuration identity and the failure reason alongside the verdict.

That last habit is what makes the difference between automation that helps and automation that hides problems. "Office VPN: disconnected, last attempt failed at authentication" tells an operator where to look. "VPN is down" invites a reinstall, and "interface found" invites a false all-clear.

The Network Extension reference for loading saved tunnel configurations is the place to confirm the calling-app scope before you build anything on top of it.