Why a Local Route Beats Your VPN Default Route

A printer on the desk keeps working after the tunnel comes up, while a server at the other office quietly resolves to something local. Both behaviours come from the same rule: the most specific route wins, and a directly attached prefix is as specific as it gets. That is usually the design you want, and it is also how a duplicate private range steals a remote address. Reading the kernel's choice first turns a mysterious failure into a prefix comparison.

A Connected Prefix Is More Specific Than a Default

A tunnel typically installs a default route or a set of prefixes, while a local interface carries a connected prefix plus a route to the whole LAN. Longest-prefix match decides between them, so a destination inside the LAN prefix never reaches the tunnel. That is why a printer, a router's administration page and a local NAS stay reachable while the VPN is up. It is also why a remote resource inside an overlapping range goes to the wrong machine.

Private address space is not unique, and two sites choosing the same prefix is common enough to plan for. When the ranges overlap, the local answer arrives quickly and looks authoritative, so the failure is easy to misread as a login problem. The destination did answer, just not the one you meant.

Read the Choice the Kernel Would Make

Ask the kernel which route it would use for the exact destination rather than reading the table from the top. Then look for policy rules that could select a different table. Two commands answer both questions in a few seconds.

ip route get 10.20.30.41
ip route show table all | grep -E '10\.|default'
ip rule show

The first output names the interface, the next hop and the source address the kernel would use, which is the answer that matters. A dev value pointing at the local bridge means the packet never enters the tunnel, whatever the VPN client's status panel claims. The filtered table listing shows whether another table holds the same prefix, and the rule list shows the order in which those tables are consulted. A policy rule can send a prefix through a specific table even when the main table disagrees, so that order is part of the answer.

Local Access Is a Separate Permission

Having a route is not the same as being allowed to use it. Most clients can block local network communication while the tunnel is up, and that setting is a policy decision rather than a routing artefact. When a trusted nearby service belongs in the design, enable the supported local-access option instead of inventing routes. When the device is on public Wi-Fi, leave it off.

The two layers fail differently. A blocked local path produces a timeout even though the route exists, while an overlapping route produces an answer from the wrong host. Distinguishing them takes one query and saves an afternoon of firewall changes, and the forwarding arrangement is described in strongSwan's forwarding notes.

Fix an Overlap Without Host-Route Sprawl

A host route for one address appears to fix an overlap and fails the moment a second address in the same range is needed. Twenty of them later, nobody can say which prefix is authoritative. The durable fixes are a change of addressing, a documented topology that avoids the duplicate range, or translation at one end. Each costs planning time once rather than maintenance forever.

If a temporary host route is genuinely required, record the reason, the owner and the date beside it so it can be removed later. Then test the exact address and service plus a public destination, because a local-access change that quietly excludes unrelated applications from the tunnel is worse than the original fault. Keep the local prefix and the remote prefix written down separately; that habit stops a working local ping from being passed around as evidence that the remote office is reachable.