A VPN on Windows 11: The Adapter, the Route, and the Resolver

On Windows there are two genuinely different things called setting up a VPN: configuring the client that ships with the operating system, or installing a provider’s application that brings its own virtual adapter. They differ in which connection types they can speak, in what happens the moment a tunnel drops, and — most consequentially — in how the machine resolves names afterwards. Windows is unusually good at letting you see all three of those things, which is the reason to learn the vocabulary rather than follow a menu path.

Two mechanisms wearing one name

The client built into Windows expects to be handed configuration by somebody else. You supply a server address, a credential, and a connection type drawn from a fixed list that the operating system implements. It was designed for reaching an employer’s or an appliance’s remote-access service, and that is still what it is good at. If somebody has given you a server name and a login, this is the right tool and no additional software is needed.

A consumer provider’s application does something different. It installs a virtual network adapter, usually backed by a driver and a background service, and then manages the tunnel itself. Because it brought its own machinery, it can implement connection types the built-in client never learned, apply rules per application, and enforce a fail-closed state using firewall rules. The app is not a convenience wrapper around a Windows feature; it is where the features live.

Knowing which of the two you are using answers most later questions. The built-in client has no kill switch and no per-application routing because those were never part of it.

The adapter is the diagnostic surface

Windows models a tunnel as a network adapter, and that is a gift. Once connected, the machine has an extra interface with its own address, its own resolver setting, and its own entries in the routing table. Everything worth knowing is visible there rather than inside the application’s window.

Which interface carries the default route decides where ordinary traffic goes. Windows chooses among interfaces using a numeric metric, and a tunnel adapter gets priority by having a lower one than the Wi-Fi or Ethernet adapter underneath it. When somebody reports that the VPN says connected but traffic is clearly not going through it, this is where the answer usually is — a metric that did not change, or a more specific route that wins over the tunnel’s. Reading your own network settings is how you check, and it takes less time than restarting the app hopefully.

The corollary is worth stating: a healthy indicator in the application is a claim about the application, not about the routing table.

Why name resolution is the part that bites

Windows has long been willing to ask more than one resolver at a time. When a machine has several connected interfaces — a tunnel adapter plus the Wi-Fi it runs over — the operating system’s name resolution has historically been prepared to send queries out of more than one of them and use whichever answers first, rather than strictly confining lookups to the interface holding the default route. Successive Windows releases have narrowed where this applies, but the behaviour is the reason this platform deserves a specific warning.

The failure it produces is invisible. Traffic goes through the tunnel exactly as intended, while a copy of every name you looked up went to the resolver the local network handed you. Pages load. Speeds are normal. Nothing in the application suggests a problem. What you have lost is the record of which sites you visited, to the party best placed to keep it.

So on Windows, verify resolution first rather than last. What matters is what the VPN’s DNS setting actually changes once it is applied, and whether the answers are coming from the resolver you expected. An application that sets its resolver on its own adapter and stops there has not necessarily stopped the machine asking elsewhere. Applications that also install firewall rules blocking lookups from leaving other interfaces have, which is one of the more meaningful differences between clients and is rarely advertised in those terms.

The other address family

Windows enables the newer addressing family by default, and a tunnel that only carries the older one leaves a hole. If a destination is reachable both ways, the machine will often prefer the newer family — and if that traffic is routed outside the tunnel, a share of your connections simply bypass it while everything appears to work. This is the IPv6 leak in its most common habitat, because desktop operating systems are where dual-stack connectivity is most likely to be fully configured. Either the tunnel carries both families or the client disables the one it cannot carry; anything else is a gap.

Sleeping, docking, and moving between adapters

Every one of those events rebuilds the interface list. A laptop that wakes on a different network, or is plugged into a dock and switches from Wi-Fi to Ethernet, has changed the path underneath the tunnel. Clients handle this with varying grace, and the question worth asking is not whether it reconnects — almost all of them do — but what the machine did during the seconds before it did. That is the fail-open or fail-closed decision showing up in practice, on the platform where laptops change networks most often.

Removing it is not the same as uninstalling it

Adapters, drivers, services, and firewall rules can outlive the application that created them. Removing a provider’s software does not reliably remove the virtual adapter it added, the service it registered, or the firewall rules it installed to enforce fail-closed behaviour. The symptom to recognise is a machine that behaves oddly after the VPN is gone: some connections refused, or names resolving strangely, because rules written to block traffic outside a tunnel are still in force and there is no tunnel left. Check the interface list for adapters that should no longer exist, and check whether anything is still setting a resolver on them.

If a specific site or service keeps resolving to somewhere unexpected after a change, that is a cache question rather than a configuration question, and the two are worth telling apart before you start editing settings. Everything above assumes you have already decided which layer should be carrying the tunnel at all; if not, that decision comes first.