How to Remove a Stale Route Left by a Windows VPN

Your session ended hours ago, the adapter is gone, and the route is still in the table pointing at interface 42. Deleting that row takes one command; deciding that it is the right row takes four checks. A route table is shared, so a broad removal takes out paths that other connections still use, including the one that carries the tunnel. Each step below narrows the target until only one entry can match.

1. Decide whether the entry is stale or intentional

An entry that survived a reboot was written somewhere, and that somewhere is usually a decision rather than an accident. Split tunnelling depends on routes that look exactly like leftovers, and a policy that pushes one prefix through the tunnel is indistinguishable from a stale entry in a single listing. Ask when the route appeared: one that exists only while the tunnel is up belongs to the client's configuration, so a cleanup command is the wrong tool. Remove a deliberate route and the next connection fails at the step nobody is watching.

The endpoint route deserves its own warning. When a client adds a host route to the VPN server so that encrypted packets can reach it over the local connection, deleting that route collapses the tunnel on the next reconnect, and the symptom reads as a server fault. Compare the destination with the address the client connects to before touching anything: a single public address that matches the VPN server is the outer path, not litter.

2. Record the four fields that name the entry

A prefix alone is not an identity, because two interfaces can hold routes to the same destination. Note the destination prefix, the interface index, the next hop and the policy store, since those four values describe exactly one entry. One listing gives you all of them:

Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric

Sorting by metric lifts the routes the machine actually prefers, which is where a leftover usually sits. Compare the entry while the tunnel is up and again after it drops: a route that leaves with the adapter was the client's, and one that stays was written by something else. The policy store is the field people skip, and it is the one that explains a reappearance, because an entry removed from the active store returns after the next policy refresh. Write the four values down before running anything that changes state.

3. Preview the removal, then remove one entry

Remove-NetRoute accepts the same prefix and interface index that Get-NetRoute printed, and it has a preview switch, so nothing has to be guessed. Run the pair in this order:

Remove-NetRoute -DestinationPrefix 10.20.0.0/16 -InterfaceIndex 42 -WhatIf
Remove-NetRoute -DestinationPrefix 10.20.0.0/16 -InterfaceIndex 42

The preview prints the object it would delete, so compare prefix, interface and next hop against your notes before dropping the switch. Neither line reaches a persistent entry, because the active store is the default; add -PolicyStore PersistentStore when the route you identified lives there, or the removal appears to work and the entry returns at the next policy refresh. Keep an out-of-band recovery path when the session is remote, since deleting the route that carries your own connection ends it. Never reach for a command that clears the table.

4. Find whichever component puts it back

A deletion is not a fix while the owner is still configured to install the route. The owner is usually one of three: the VPN client's profile with its split-tunnel list, a script or scheduled task that adds routes at logon, or a domain policy applied to the machine. Check the profile first, because it runs at every connect:

Get-VpnConnection | Select-Object Name,SplitTunneling,ServerAddress
Get-NetRoute -PolicyStore PersistentStore

Persistent entries are visible without connecting anything, so a route that comes back after a reboot with no VPN session almost always lives in that store or in a startup script. Correct the owner there, and the manual deletion becomes verification instead of treatment.

5. Verify the lookup, the neighbours and the note

A clean result is not "the route is gone"; it is a lookup that now picks the interface you expected. Ask the machine where a packet to the affected prefix would go, because a leftover still names the dead index while a clean answer names the on-link interface or the correct gateway. Find-NetRoute answers that for one address at a time:

Find-NetRoute -RemoteIPAddress 10.20.4.7

Then test a neighbour: pick a second prefix that a split tunnel still needs and confirm its lookup is unchanged, since taking out one route too many is the mistake this cleanup invites. Retry the application that originally failed, and record which component owns the prefix now. The Microsoft Get-NetRoute documentation lists the fields you wrote down in step two. Six months from now that note is what stops the same entry being diagnosed twice.