Windows VPN DNS Leak: Why the Metric Beats the Route

A query leaves the machine and reaches the home router while every packet is being tunnelled. The natural conclusion is a missing route, and the route is usually fine. Windows can choose which interface's resolver to consult by interface metric, and a tunnel adapter frequently loses that comparison to the wireless one.

Two Explanations for One Leak

The routing explanation says some traffic is escaping the tunnel, so the default route or the split-tunnel list must be wrong. That explanation is testable in one command, and when the default route points into the tunnel it is finished. Check it first because it is cheap, and then set it aside when it comes back clean.

The ranking explanation says the traffic is fully tunnelled and the lookup is still being sent to a different resolver. Windows treats the resolver choice as a per-interface property with an order, so a physical adapter with a better metric can supply DNS for a name even though packets for the resolved address travel through the tunnel. Both explanations produce the same symptom in a leak test page, which is why the test is not the diagnosis. Only one of them is repaired by editing routes.

Compare Metrics and Resolvers Together

Record the interfaces, their metrics and their configured servers while the tunnel is up. Read them as a table rather than as two separate lists, because the question is which resolver ranks first, not which resolvers exist.

Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object InterfaceIndex, InterfaceAlias, InterfaceMetric
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, ServerAddresses

If the tunnel adapter carries a higher number than the physical adapter, its resolver is not preferred, and an internal name will go to whatever the physical side offers. That router may answer from cache, forward it onward, or refuse it, and none of those outcomes is the design you intended. The ranking is a preference, so it silently loses rather than raising an error.

A tunnel adapter with no resolver configured at all is an equally common variant. The client brings the interface up without pushing DNS, so the ranking question never even arises.

Rank the Tunnel and Recheck

Give the tunnel interface the lowest metric, or raise the physical adapter's value, in an elevated shell. Both are per-interface settings and both are reversible, which matters when you are changing a machine you may not be sitting in front of.

Set-NetIPInterface -InterfaceIndex 27 -InterfaceMetric 1
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric

The change appears immediately, and the DNS client and other consumers cache the choice they already made. Reconnect the tunnel, or restart, before reading anything into a query result. A test run too early will reproduce the old behaviour and look like a failed fix.

Then query one internal name and one public name and check which server answered. Microsoft's reference on automatic metrics explains why the lowest value is preferred and how the automatic assignment is derived.

Make It Survive a Reconnect

A manual metric on an adapter that is recreated on every connection is a setting that disappears. If the client rebuilds the interface, the override needs a post-connect script, a policy, or a client configuration that owns DNS while connected.

Statically configured servers on the physical adapter have the same durability problem in reverse. They keep answering for that interface until they are removed, and DHCP will repopulate them from the next lease, so removing them is a measurement rather than a design. The durable design is a name resolution policy for the internal namespace, or a client that takes ownership of DNS for the duration of the connection. Either way, record the resolver list before and after a reconnect, restore the original metric when you are finished testing, and confirm the previous behaviour returned.