VPN Route Metric Changed After Connecting: What It Means
A lower metric only breaks ties between equally specific routes. Read the policy rule, prefix and endpoint host route before you edit any VPN route number.
You connect the VPN, run a route print, and the default route now carries a much lower metric than before. The natural conclusion is that the VPN took the default route because its number is smaller. Sometimes that is exactly what happened. Often the metric is not the deciding factor at all, and editing it changes nothing because the choice was made earlier, by prefix length or by a policy rule.
The symptom is real: traffic that used to leave through the Wi-Fi adapter now leaves through the tunnel, or the reverse. The metric is one input to a lookup that runs in a fixed order, and that order is what you need to read before touching a number.
What the number actually competes with
The first comparison is specificity, not preference. A route for 10.20.0.0/16 beats 10.0.0.0/8, and both beat 0.0.0.0/0, whatever their metrics say. A VPN that installs a default route with the lowest metric on the machine still loses to any more specific route that matches the destination, including the host route the client installs for its own server.
That is why lowering the metric on a default cannot force a directly connected subnet into the tunnel. If you want that subnet inside the VPN, add a route for the prefix or select the tunnel table with a policy rule. The metric is the wrong lever for that job.
| Check in this order | Question | Where you read it |
|---|---|---|
| 1. Policy and table | Which routing table does this traffic use? | ip rule, client profile |
| 2. Prefix length | Which matching route is most specific? | route print, ip route |
| 3. Metric | Which of the equally specific routes is preferred? | route print, ip route |
| 4. Interface state | Is the chosen next hop reachable? | adapter status, link state |
Linux decides the table before the metric
On Linux the kernel consults the policy database first. ip rule lists the rules and the tables they select, and ip route get 203.0.113.10 reports the table, route and source address the kernel would actually use for that destination. A metric inside table 100 never competes with a route in the main table, because the rule picked the table before any metric was compared.
This is why a route can look right in ip route show table all and still not carry traffic. Read the rule that matched, then read the table it selected, then compare routes inside it. If the wrong table is selected, no metric edit in the other table will help.
Windows combines two metrics
Windows has no policy database by default, but it does combine a route metric with an interface metric, and the automatic interface metric can change with link speed and adapter state. That is why the same route can behave differently after a docking station or a virtual adapter appears. Find-NetRoute -RemoteIPAddress 203.0.113.10 reports the chosen source address, next hop and interface, which is closer to the real decision than the raw table.
Read the route and interface values together. Raising an interface metric can move traffic without any route entry changing, and a VPN client that owns its routes will reinstall them on reconnect, discarding your edit.
Keep the tunnel endpoint outside the tunnel
Every tunnel needs a path to its own server that does not run through the tunnel. Clients install a host route for the endpoint through the physical gateway, and that route must stay more specific than the default the client adds. Delete it, or make the tunnel win the lookup for that address, and the encapsulated packets try to enter the tunnel they are supposed to build. The connection fails or loops.
Check that host route before and after any metric change: it should point at the physical next hop and survive a reconnect. If the client's owns it, change the profile or managed configuration rather than a runtime value that will be overwritten.
Check both address families and the app context
IPv4 and IPv6 are separate decisions with separate tables. A VPN can carry IPv4 while IPv6 keeps using the local router, and a metric change in one family says nothing about the other. Check both, then check the application context. A process bound to an interface, a container namespace or a per-app VPN can see a different table than your shell.
Verify with the tool that reports the decision for the real destination, not the full table listing. If the chosen route is the one the design intends, stop. A metric that is not the smallest number on screen is not a fault, and forcing it to be smallest can break the endpoint path the tunnel depends on.