VPN Route Pinned to an Interface Index Breaks on Reconnect

The route worked for weeks and then started sending traffic nowhere, with the destination unchanged and nothing edited. What changed is the number: a route created against a specific interface index refers to an adapter that no longer exists after a reconnect, and the destination prefix keeps pointing at plumbing that was replaced. Adding persistence to that command does not help, because the problem was never whether the route survived a reboot. The fix is to attach the intent to the connection, which survives adapter churn by design.

Check What the Route Actually Points At

Start by reading the route entry and the adapters side by side. A route with a next hop on the VPN interface and an index that matches no current adapter is the signature of this failure; the same prefix on a different index is either a leftover or the route you actually want. Read both lists before changing either, because the interesting comparison is between the number in the route and the numbers that currently exist. If the route's index appears in the adapter list, the index is not your problem and the search moves to metrics, policy or the far end. If it does not appear, nothing has to be diagnosed further: the route is attached to plumbing that no longer exists.

Get-NetRoute -DestinationPrefix '10.77.0.0/16' | Select-Object DestinationPrefix, NextHop, InterfaceIndex, Store
Get-NetAdapter | Where-Object InterfaceDescription -like '*VPN*' | Select-Object Name, InterfaceIndex, InterfaceDescription
Get-VpnConnection -Name 'Lab VPN' | Select-Object Name, ServerAddress, SplitTunneling

The Store column distinguishes an entry that persists across reboots from one that disappears with the adapter, and that difference determines whether the fault reappears tomorrow. An entry in the persistent store that points at a vanished index is the worst case, because it survives restarts while never matching anything.

Bind the Prefix to the Profile, Not the Adapter

A native Windows VPN can carry its own route list, so the connection reuses the correct adapter whenever it comes up. The route then follows the profile rather than a number you observed once, and no script has to guess an index after each dial. Adding a prefix is also reversible through the matching removal cmdlet, which keeps the change auditable. The prefix is stored with the connection rather than in a startup script, so a profile copied to another user carries the intent with it.

Add-VpnConnectionRoute -ConnectionName 'Lab VPN' -DestinationPrefix '10.77.0.0/16' -PassThru

The Add-VpnConnectionRoute reference documents the connection association, and the phone-book scope matters: a per-user profile and an all-user profile are different objects. This mechanism belongs to Windows' own VPN client, so a vendor adapter managed by its own service may take its routes from a different policy source entirely.

Clear Old Routes Before Adding the New One

Two routes with the same prefix and different owners is worse than one wrong route, because the winner depends on metrics that nobody wrote down. Inspect what already exists for the prefix, including entries in the persistent store, and remove only what belongs to the failed attempt. A leftover from a previous design is common in this area, since the failing route usually replaced something that used to work. Note which entries belong to which connection before removing anything, and keep the list in the change record.

Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like '10.77.*'
Remove-NetRoute -DestinationPrefix '10.77.0.0/16' -NextHop '0.0.0.0' -Confirm:$false

Match on prefix, next hop, store and owner together rather than deleting everything that looks similar. Another connection may legitimately depend on part of that space, and a sweeping delete converts a tidy repair into a support incident.

Reconnect in a Different Order

Reproduce the condition rather than hoping the first attempt was representative. Disconnect, reconnect, and confirm the selected path to the same remote resource while the tunnel is up; with several VPNs in play, bring them up in a different order and watch whether the chosen path changes. Order is the variable most people skip, and it is the one that exposes a route attached to the wrong connection.

rasdial 'Lab VPN' /disconnect
rasdial 'Lab VPN'
Find-NetRoute -RemoteIPAddress 10.77.5.20 | Select-Object -First 1

The result you want is not that an adapter keeps its number once. It is that the route appears with whichever number the connection receives, every time, and disappears when the connection closes. Reconnecting twice is the cheapest way to tell those outcomes apart.

Know What the Route Cannot Do

A profile route supplies a path and nothing else. It does not open a remote firewall, create a return route at the far end, or resolve two sites that use the same address range; each of those is a separate configuration with a separate owner. Confirming the path is therefore the beginning of the acceptance test rather than the whole of it.

Keep the prefix list with the profile and note the scope it was added under, so the next person can read the intended design instead of inferring it from a route table. Routes that exist only in someone's memory are the ones that get rebuilt wrongly after the next reconnect. A one-line comment in the deployment notes costs less than an afternoon of rediscovery.