Why a Deleted VPN Route Comes Back After Reconnect

A route you deleted by hand is back after the next reconnect, and the table looks exactly as it did before. That is not a routing bug: something recreates the entry from configuration or from a connection lifecycle action. Most runbooks stop at the live table, which is why the deletion appears to work for a minute and then fails. Identify the owner, change that, and prove it on a reconnect.

Who installed the route

Start with a list of candidates rather than a fix. A VPN profile can carry its own routes, a server can push them at connect time, a network manager profile can declare them, a boot unit or script can add them, and IPsec implementations install routes for the traffic selectors they negotiate. Policy routing rules can also redirect traffic to another table entirely.

Timing separates them faster than configuration archaeology. An entry that appears the instant the interface comes up belongs to the client; one that arrives a second later usually came from a server push; one present at boot belongs to saved configuration. Record the table before and after a connect, a disconnect and a reboot, and the pattern names the owner. A route that only returns when the service restarts points at a unit rather than at the VPN.

Read the table before editing it

Look at the kernel's own view rather than a saved file. The protocol column shows what installed each entry:

ip route show
ip route show table all
ip rule show

The protocol field, the metric and the table number tell you whether you are looking at a static entry, a kernel-created one or something a daemon added. The rule listing matters because a lookup can leave the main table entirely, which makes an edit there invisible to the application you are troubleshooting. Read the line left to right: destination, gateway, device, protocol and metric.

Then ask the kernel which route it would actually use. A protected address is a better probe than a public one:

ip route get 10.20.5.7

Change the owner, not the symptom

Once the owner is known, the change belongs in that owner. Remove the route from the client profile, correct the pushed route on the server, or edit the network manager connection rather than adding a competing persistent route that wins by metric. Two rules fighting each other produce a table that nobody can explain later.

Keep the endpoint exclusion. A host route that sends the VPN server's own public address through the physical gateway is what keeps the outer tunnel packets flowing; delete it and the tunnel tries to carry itself. On a split-tunnel profile, the same care applies to the local subnets that are meant to bypass the tunnel.

Reconnect and verify both paths

Reconnect, then check both destinations in one pass. The protected address and the excluded endpoint answer different questions:

ip route get 10.20.5.7
ip route get 198.51.100.20

The first should resolve through the tunnel interface and the second through the physical gateway. If both resolve through the tunnel, the exclusion is missing; if neither does, the profile change did not take effect and you are looking at a different owner than you thought.

Write down the route's purpose, its owner and how long it should live. That note is what stops the next person from repeating the same delete-and-reconnect cycle.