Inspect Linux policy routing before you edit the default route

A VPN host answers on one interface and refuses to send replies back through the tunnel, and the default route looks correct. That is the point where the main table stops being the whole story. Linux can select a routing table per packet using policy rules, and the VPN may have installed one. Read the rules before you touch the default route.

The order matters: rules first, then the table each rule selects.

Read the rules in priority order

Run ip rule show and read top to bottom. The priority number controls evaluation order, and a lower number is checked earlier. The default rule at 32766 is usually the last one that matters. If the list is long, save it to a file before you change anything.

For each rule, record the priority, the match (source, mark, interface, or destination) and the table it references. A rule without a usable table is a dead end, not a route.

Do the same for IPv6 with ip -6 rule show. A policy that exists only in the IPv4 family leaves the other family on the main table.

Read the table each rule selects

Use ip route show table <name or number> for each referenced table. Compare its routes with the interface and next hop you expect. An empty or incomplete table explains a failure that the main table cannot.

The main table may still hold the default route, and that is fine. If a rule sends your flow to table 51820 first, the main default is irrelevant to that packet.

Look up the table name in /etc/iproute2/rt_tables if the number is unfamiliar. That lookup takes a second and prevents a long detour.

Find who installed the rule

NetworkManager, wg-quick and other scripts can install rules dynamically. Deleting one at runtime may be undone at the next reconnect. Check the manager's configuration before adding a competing rule.

wg-quick, for example, adds a marked rule and a table for the tunnel's allowed addresses. That rule is why traffic to those addresses bypasses the main default. If you remove it without changing the configuration, the next up will restore it.

Preserve the endpoint's outer route and management access while you review. Do not flush all rules on a live remote gateway to simplify the output. A management session that survives the change is part of the test.

Test the source context that matters

A generic ip route get answers a different question than the application flow. Add the source address, and the mark if the VPN uses one, to see the path the real packet takes. Test an included destination and an excluded one with the same source context. Then repeat for IPv6 if the host runs dual stack.

After an approved correction, re-run the same two lookups and compare. Keep a record of the intended rule, the table, and how long the rule survives a restart. That record is what makes the next service restart explainable instead of mysterious. The ip-rule manual page documents the match selectors and table syntax.