VPN and container routes overlap a local network · Linux Fix Lab

Symptoms & scope

A local host becomes unreachable only while a VPN or container network is active.
Traffic for the destination is selected onto the wrong bridge, tunnel or policy table.

Relevant environment

Hosts with multiple routing tables, VPNs, virtual bridges or container networks; network namespaces can have separate route decisions.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

A virtual subnet can overlap the LAN or corporate VPN subnet, making a local connected route compete with the intended path.
Policy rules or a more specific prefix can select an unexpected table or interface; a default-route metric change does not override every collision.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Replace DEST_IP with the confirmed affected IP, not a hostname; use ip -6 route get for IPv6. This asks the kernel for its route decision without sending a packet.

ip route get DEST_IP

Interpret the result: Compare selected dev, source, gateway and table with the intended network. Run the query in the affected namespace if the failure is inside a container rather than on the host.

Check 2

Read the routing policy database in priority order without adding or deleting rules. Use ip -6 rule show for the IPv6 policy database.

ip rule show

Interpret the result: A rule can select a non-main table before normal destination routing. Marked traffic, source-specific rules or VRFs may require a route query matching the affected flow.

Check 3

Read IPv4 route tables, including virtual and VPN paths; use ip -6 route show table all for IPv6. No table is flushed.

ip route show table all

Interpret the result: Identify equal or nested prefixes and the rule-selected table. Longest-prefix selection precedes metric comparison among otherwise comparable routes in that table.

Evidence-guided next steps

Renumber a confirmed overlapping virtual subnet

If the collision is an internally controlled VM/container bridge, choose an approved private subnet that does not overlap the documented LAN or VPN ranges. Save that platform’s network definition, update the bridge and its attached workloads together, and compare the original destination.

Precautions: Renumbering can interrupt containers, port bindings and local services. Do not change a corporate VPN range or assume any popular private subnet is collision-free.

Recovery / rollback: Restore the saved bridge/subnet and workload addresses if local services fail; stop the conflicting virtual network temporarily while recovering access.

Did this solution help you?

Share this solution #

Correct the specific managed route or rule

If the required path is documented and renumbering is not appropriate, correct the exact destination route or policy rule in the manager that owns it, using its intended reachable gateway/table. Verify the same flow’s route decision before making the change persistent.

Precautions: Record rule priorities and routes, keep local access, and use a checkpoint where supported. A more specific route cannot make the same IP identify two distinct hosts on two networks simultaneously.

Recovery / rollback: Remove only the new route/rule or restore the saved profile, then reconnect the original VPN/bridge through the available local recovery path.