Which Route Wins When the Tunnel and the Local Network Disagree

A connected device does not hold one instruction about where to send traffic. It holds a table of overlapping claims — this range goes out the Wi-Fi adapter, this range goes out the tunnel, everything else goes to the gateway — and for any given destination it picks exactly one of them. The rule it uses to pick is simple, it is the same rule on every platform, and once you know it the most confusing VPN failure of all stops being confusing: the tunnel is genuinely up, the client reports success, and your traffic is not going through it.

That failure is not a bug in the tunnel. It is the routing rule producing the answer it was always going to produce.

A routing table is a set of overlapping claims

Each entry names a range of destinations, an interface to send them out of, and usually a priority number. Overlap between entries is normal and expected, not a misconfiguration.

The widest possible claim is the default route, which matches every destination there is. On an ordinary connection it points at your gateway, and it is the entry doing almost all the work: anything that is not on your own network matches nothing more specific and goes there.

Alongside it sits at least one narrower claim — the range covering your own network, pointing out the physical adapter with no gateway involved, because those destinations are reachable directly. That is already an overlap. A local printer matches both the local range and the default route.

Most specific wins, and priority is only the tie-breaker

When two entries both match a destination, the one covering the smaller range is used. The local printer goes out directly rather than to the gateway because the local range is a narrower claim than “everything”.

Only when two matching entries cover ranges of equal size does the priority number decide, and platforms name that number differently — metric, priority, preference. This ordering matters more than it sounds, because it means a low priority number cannot rescue a broad claim from a narrow one. A carefully preferred default route still loses to any more specific entry pointing somewhere else.

Stated as a worked example with invented numbers: if one entry claims a range of 256 addresses out of the tunnel and another claims a range of 16 addresses inside it out of the local adapter, those 16 go local no matter what priorities are attached, and the other 240 go through the tunnel.

The tunnel does not delete your existing route, and should not

A VPN client cannot simply remove the default route it found, because it still needs the physical path to reach the VPN server. Its own encapsulated packets have to get out somehow.

So a connecting client typically adds three kinds of entry rather than replacing anything:

• A narrow route for the VPN server’s own address, pointing out the physical adapter. Without it, the tunnel’s packets would be routed into the tunnel, which cannot work.
• A route for the tunnel’s own network, so the virtual interface’s peers are reachable.
• Something that outranks the existing default route for everything else.

That last item is where implementations differ, and both approaches follow from the rule above. Some clients install a default route through the tunnel with a better priority than the physical one, an equal-size claim decided on the tie-breaker. Others install two routes that each cover half of all addresses, which together cover everything while each being more specific than any default route — winning on specificity rather than on priority, and therefore winning regardless of what priority the physical default was given.

The practical consequence: seeing your old default route still listed after connecting is not evidence of a leak. It is expected. What matters is which entry actually matches.

Where the local network gets a vote

A network you join hands your device configuration when it joins, and routing information can be part of that. A route learned from the network is an ordinary entry in the same table, subject to the same rule as everything else.

Which means a route advertised by the local network that is more specific than the tunnel’s default outranks the tunnel for the destinations it covers — by exactly the mechanism that let the tunnel outrank the physical default in the first place. The precedence rule is symmetric and has no concept of which entry belongs to software you trust.

This is the clearest argument for a distinction made elsewhere on this site: enforcement by packet filter is different in kind from enforcement by routing. A filter that drops anything not leaving via the tunnel interface does not care which entry matched, because it acts after the decision. A tunnel whose only guarantee is a favourable routing entry inherits whatever else lands in the table. The difference shows up in how a VPN kill switch fails closed.

Reading the outcome instead of assuming it

The table is a fact you can look at, which makes this one of the few privacy questions with a definite answer available locally. Four steps:

1. List the routes, using the platform commands in how to read your own network settings.
2. Find every entry that matches a destination you care about, then apply the rule: smallest range first, priority only among equals.
3. Confirm the winner points at the tunnel interface, not at your physical adapter.
4. Do it again for the other address family. An IPv4 default route through the tunnel says nothing whatsoever about where IPv6 traffic goes, and the two tables are separate — the reason several IPv6 addresses can quietly stay usable outside a tunnel that looks complete.

If the winner for ordinary destinations is the tunnel interface and the local range still has its own entry, the routing side of your setup is correct and any remaining problem is elsewhere — resolver configuration, application behaviour, or the far end.

The failures this rule explains

• The tunnel is up and nothing uses it. Nothing outranked the physical default, so every destination still matches it. Common after a client crash or an update that changed how routes are installed.
• Local devices become unreachable. The entry for your own range was removed or overridden, so the printer now matches the tunnel’s claim and is sent through it.
• One application behaves differently from the rest. Routes match destinations, not programs. If two programs contacting the same address take different paths, something is applying policy per process instead — the mechanism behind split tunnelling.
• Everything looks right and the exit address is still yours. Check for a second physical interface with its own default route, and check whether a more specific entry is quietly capturing the destination you are testing with.

Why this is the layer worth learning

Most of what a VPN promises is a claim you have to take on trust: what is retained, what is examined, who owns the company. The routing table is the opposite. It is a short list, it lives on your machine, it is generated by software rather than written by marketing, and it answers “is this traffic going through the tunnel” with a definite yes or no.

Learning to read four or five lines of it converts the most common VPN complaint from a suspicion into an observation, which is the whole point of working from the device outward.