Windows VPN: saved profile versus the active interface state

A Windows VPN appears in two places that answer different questions, and confusing them produces a confident wrong diagnosis. The saved profile says what someone configured; the active interface says what the stack applied just now. When a connection establishes and traffic still takes the wrong path, both views have to be read, in that order. Neither one alone tells you whether the application's packet left through the tunnel.

Two views of the same tunnel

The profile view is configuration: server address, tunnel type, authentication method, split-tunnel settings. It can be correct while the connection ignores it, and it can be stale while the connection works perfectly, because a client that reconnects may not re-read what you edited. The interface view is applied state: which adapters exist, which address families they carry, their metrics and their connection state. It changes as tunnels come and go, which makes it the right place for a live routing question and the wrong place for a configuration one.

Reading them together is the whole method, and reading either alone is how people end up deleting a healthy adapter. The commands below produce both views without changing anything.

Read both views without changing anything

Start with the saved profiles, because that is the cheapest fact to confirm. Note the tunnel type and the split-tunneling value, since both decide which destinations are supposed to enter the tunnel at all. If the profile is wrong, fix it through its supported configuration surface, because nothing in the interface list repairs a profile that points at the wrong gateway.

Get-VpnConnection | Select-Object Name,ServerAddress,TunnelType,SplitTunneling,ConnectionStatus

The interface view has a different shape: one tunnel may occupy two rows when it carries both address families. Read the index as the identity and the alias as a label someone chose, and expect the alias to change between client versions.

Get-NetIPInterface | Select-Object InterfaceIndex,InterfaceAlias,AddressFamily,ConnectionState,InterfaceMetric

Presence is not proof of use, because an interface can exist, be connected, and still not be the one your destination's route selects. Keep that in mind before treating an unfamiliar adapter as the fault. Those two failures look identical from the outside: a correct profile with a route that never uses it, and a wrong profile with a route that does. They have completely different fixes, which is why the next section exists.

Follow the route to the destination

Ask the stack which path it would take for the address the application actually contacts. That is the question the interface list cannot answer on its own.

Find-NetRoute -RemoteIPAddress 10.60.20.10 | Select-Object -First 1
Get-NetIPAddress -InterfaceIndex 37 | Select-Object IPAddress,AddressFamily,PrefixLength

The first command reports two fields worth reading: the interface alias of the selected source, and the next hop for that destination. The index 37 in the second command is whatever the first output printed, not a constant to copy, and the address 10.60.20.10 is illustrative. If the chosen source belongs to the physical adapter while the destination should be inside the tunnel, you have found the selection problem, because the VPN interface may be perfectly healthy and simply not preferred. A metric is only part of that decision, since route specificity, policy and interface state all participate.

Compare three states under the same conditions

Record the interface list and the chosen route before connecting, while connected, and after disconnecting, using the same destination and the same commands each time. That comparison separates a current tunnel interface from an old hidden adapter left by an uninstall, and from a second client that is also running. It also tells you whether the tunnel interface disappears cleanly, since an adapter that persists after disconnect is a different problem from one that never appeared. Without the three snapshots, every unfamiliar alias looks like the culprit.

Keep the three outputs with the ticket, because two command outputs beat a paragraph of description. A colleague can compare them without repeating your session at all.

Do not delete what you did not identify

Unfamiliar adapters usually belong to something: a managed client, a virtual switch, a container network or a security agent. Deleting one can remove a working component and leave the original symptom exactly where it was. If the route is stale, find the route owner and fix it there; if the profile is wrong, edit the profile. The Get-NetIPInterface documentation lists the fields used above, including the metric and state columns that make the comparison meaningful.

Name the object, find its owner, then act on that owner. Anything else is renaming the problem rather than reading it.