OpenVPN route metric: why the chosen route still loses

You added a metric to a route in the profile, reconnected, and traffic still leaves through the wrong interface. The number is rarely the problem. A metric only orders candidates that the operating system is already comparing, and a more specific prefix or an earlier policy table decides before any metric is read.

Work through the profile first, then the installed table, then the selection rules. That order matches the way the client builds the route and stops you from tuning a value that never enters the comparison.

Read the route line in field order

A Community OpenVPN 2.6 client accepts four fields on an IPv4 route line: network, netmask, gateway and an optional metric. The gateway position is where the special vpn_gateway keyword goes. It means the VPN-side next hop for this connection, not a routing table number and not your physical router. Miss that and the rest of the line is being read with the wrong idea of what it does. The network-options reference documents all four fields.

For a private destination the line can read:

route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30

The explicit 30 applies to that route, and the 50 stays the default for every other route in the profile that omits a number. Reading the line left to right is enough to tell which value applies where.

route-metric is a default, not a rank

route-metric sets the fallback for routes that do not carry their own number. It does not push a route above anything else, and it does not reorder routes that were installed with explicit metrics.

That distinction matters when a profile mixes both forms. A single route-metric line near the top looks authoritative and is easy to blame, while the route that actually carries traffic may carry its own metric three lines down.

If you want one route to prefer a path, put the number on that route. If you want a consistent default across a generated profile, use route-metric and leave the individual lines alone. Mixing the two without a reason is how a profile ends up with a route nobody can explain.

Inspect what the client installed

After the reconnect completes, ask the kernel rather than the profile.

ip route show lists the routes the client added, and ip route get 172.20.5.10 answers the more useful question: which route this destination would actually use, with which source address. If the destination is missing from the table, the client did not install it.

A local directive, a server push or another network manager can add or remove the same prefix, and the last writer wins. Keep the endpoint route in view while you work, because the connection needs a path to the remote server that does not run through the tunnel it is building.

Why a smaller metric still loses

Metrics compare routes to the same destination. They do not make a broad prefix more specific. When redirect-gateway def1 is in play, the client installs 0.0.0.0/1 and 128.0.0.0/1, and those two prefixes cover the whole IPv4 space more specifically than 0.0.0.0/0. A metric of 1 on the default route does not outrank them.

The same logic applies to any overlapping pair. A /24 beats a /16 for an address inside it regardless of the numbers attached, because the lookup chooses the most specific match first and only then compares metrics among equals.

This is the part that looks like a metric bug and is not one. Check the prefix length on both candidates before you change any number.

Policy rules run before the table

On Linux, ip rule decides which routing table is consulted. Rules are evaluated in priority order, so an earlier table can return a route before the main table is ever read. A metric inside main cannot outrank a match in a table that was consulted first.

Use ip rule show and then query the specific table, for example ip route show table 100, to see what that rule would return. If a VPN client or a container runtime added a rule, the answer may be there rather than in the table you have been reading. Source address matters too, since a rule can match on the source and resolve the same destination differently for tunnel traffic and LAN traffic.

Verify the destination, not the ranking

The test that ends the argument is a single query to a host inside the intended subnet, plus a check of the source address the kernel selected. If that pair matches the design, the metric is doing its job even when the listing does not look like a clean ranking.

Leave IPv6 and DNS out of this check. They are configured by different directives and resolved by different mechanisms, and a working IPv4 route says nothing about either. Change one layer at a time and re-run the query.