macOS VPN Route Check: route get Without Changing Anything

A user reaches the intranet on the office network and not through the tunnel, while Settings still shows the VPN as connected. Editing the route table at that moment risks cutting the remote session you are using to diagnose. Ask the kernel which path it would choose for the failing host instead. The macOS route utility has a get operation that answers exactly that, for one destination, without changing anything.

Query the host that fails, not the default

A screenshot of the default route tells you very little on a modern Mac, because a more-specific destination or scoped policy can override what the default appears to say. The tunnel can be up, the default can look correct, and the single host you need can still be routed elsewhere. Query the address that fails and let the kernel name the path it selected.

The form is route -n get followed by the address: route -n get 203.0.113.10, where the documentation address stands in for your target. Use the authorized destination and the matching address family, because an IPv4 answer says nothing about an IPv6-only resource. The route utility documentation describes the get operation and the fields it prints.

Read the interface and gateway as evidence

Run the query before connecting the VPN, then again after, and compare the interface and gateway lines. The delta between those two answers is what the tunnel actually changed, and it is far more useful than a full table dump. If the interface is identical in both runs, the route was never the problem and you can stop looking at routing.

Record the destination, the interface, the gateway and the time of the query before you draw a conclusion. The output is evidence, not a diagnosis: the same interface can be correct for one host and wrong for another when a split tunnel is involved.

A correct route is not a working request

A route tells you which interface the kernel would use, nothing more. DNS, a host firewall and application authorization all sit above that decision, and the request can fail after routing succeeds. Preserve the exact symptom before moving on, because "cannot connect" and "connects but returns an error" are different investigations with different next steps. The resolver view and the interface view complement the destination query rather than replacing it.

A routing-table listing still has a place: it is how you notice an unexpected default. A remaining ordinary default does not prove the VPN is unused, because more-specific entries win over it.

Keep the endpoint and the resource apart

Two lookups are involved and they answer different questions. Reaching the endpoint is an outer journey across the physical network. Reaching the application happens inside the tunnel, at an address that only exists on the private side. Confusing the two produces the classic false loop, where the endpoint seems to route through the tunnel it terminates. Query both addresses separately, label each result, and the confusion disappears.

Prefix overlap is the other case worth knowing. When local and remote ranges overlap, the longest-prefix match decides, so an overlapping local subnet can shadow the remote address you expected. The private destination then looks identical to a local one, and the fix belongs in the address plan rather than in the route table. The get query shows which interface won, which is the fact you need before changing anything.

Read first, change later

Keep route add and route delete out of the first pass. On a Mac you administer remotely, one careless table edit can take away the very path back to the machine, leaving nobody able to finish the diagnosis. Decide what the correct route is, write down how to undo the change, and only then run it. Inspection has no such tail.

The same caution applies to flushing caches and restarting network services as a first move, because both destroy the evidence you were about to read. Read-only checks are cheap, repeatable and safe to run in any order. Make them the default step, and reach for a change only when the evidence points at one.