A VPN Default in Table 200 Hides Your LAN Route

Four checks separate a policy-table fault from a routing fault: which rule matched, which table that rule named, what that table contains, and which route inside it won. The main table is not consulted once an earlier table produces a route, so a LAN entry visible there can be irrelevant to the packet you are testing. Work the checks in order, and the missing route shows up at the third step rather than the fourth.

Longest-prefix matching happens inside one table; it does not compare every table's routes as a single list.

The Lookup Ends at the First Table That Answers

Take a policy where traffic from a subnet looks up table 200 first, table 200 holds a default route through the tunnel, and the main table holds the LAN prefix. A packet for a LAN address can match that default in table 200 and stop there. Because the lookup produced a route, the later main-table rule never gets to offer its more-specific entry. The result is a packet that enters the tunnel while a perfectly good LAN route sits unused.

Earlier rules and the machine's own local-address lookup still apply, so the test has to use the source, mark and interface that the real flow carries. Query with anything else and the LAN may be selected correctly, which conceals the very fault you are hunting.

Put the LAN Exception Where It Belongs

The selected table can carry the LAN, connected and endpoint routes it needs, which keeps the policy self-contained. Another design uses an explicit earlier rule for the LAN prefix, or a deliberate throw route that hands a prefix to a later lookup. Each is a legitimate pattern with a different owner. Choose on the intended policy and on who maintains the routes, not on which one is shorter to type.

Whatever the pattern, the exception must be visible where the policy is defined. A route added by hand and not recorded will disappear at the next reboot and take the diagnosis with it.

Do Not Copy the Main Table Wholesale

Copying every route from main into the policy table looks like a fix and creates a snapshot. A manager may add or remove addresses and interfaces dynamically, and the copy goes stale without anyone noticing. Keep the route lifecycle with its configuration owner, and regenerate the table from configuration rather than from a moment in time.

A copied table also defeats the purpose, because it reproduces the fallback behaviour the policy was meant to constrain.

Check Replies Separately From Routes

Once the lookup selects the intended path, replies can still fail for reasons that have nothing to do with the table. Translation may be applied on the wrong interface, reverse-path validation may reject a packet that arrived by an unexpected path, or the endpoint may simply not answer. Those are distinct faults with distinct evidence, and none of them is repaired by editing route entries.

Save the lookup for that exact flow either side of the change, so the correction stays visible. Disabling reverse-path checks globally or flushing rules supplies no missing route and weakens unrelated controls.

Record the rule, the table, the winning route and the reply path. That record separates a policy mistake from a broken service.