Windows VPN DNS Wrong Server: Metric, Bind Order or Suffix

A Windows client can hold a working tunnel, carry the corporate resolver, and still send internal names to the home router. Three different mechanisms decide which server answers, and they fail in different ways. You do not have to fix all three: the symptom tells you which one is in play. The decision tree below takes a few minutes and prevents the usual outcome, where a metric change, a registry reorder and an NRPT rule land together and nobody knows which one did anything.

Three mechanisms decide, and usually one is wrong

The interface metric orders adapters for a given address family. The binding order under Tcpip\Linkage is a machine-wide list of interface identifiers that older code paths still consult. The Name Resolution Policy Table binds a namespace to specific servers, and the suffix list decides whether a short name is expanded at all. They are independent, which is why a correct resolver on the VPN adapter loses to a stale preference elsewhere.

None of these mechanisms is the far side of the tunnel. If the server the VPN pushes cannot resolve the name, every client-side setting is decoration, so the first decision is whether the resolver itself can answer when asked directly.

Decision one: can the pushed resolver answer at all?

Ask the server explicitly and compare that with an ordinary lookup. The gap between the answers separates a selection problem from a reachability problem, and it is the fastest fork here:

Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type A

If the first succeeds and the second fails, the resolver is reachable and Windows is choosing badly; go to the namespace and order decisions below. If the first fails too, nothing on the client will help: check that UDP and TCP 53 reach the server through the tunnel, that no host firewall on the server drops the pool, and that the server's own forwarders are healthy.

Stop at this fork. Applying an NRPT rule to a resolver you cannot reach produces the same failure with more configuration to undo, and it hides the real fault behind a rule that looks authoritative.

Decision two: one namespace, or every query?

Scope decides the tool. When only corporate names fail, bind the namespace instead of reordering the machine: an NRPT rule sends that suffix to the tunnel resolver and leaves everything else alone. When every lookup is affected, the problem is global adapter preference, and the metric is the place to start because it changes no server setting.

Set the metric per address family, on both interfaces, and confirm the ordering afterwards:

Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv6

Replace 11 with the tunnel adapter's ifIndex from the line above; if 11 is the LAN adapter, the same command lowers the wrong path. Raising the LAN adapter instead reaches the same ordering from the other side: netsh int ip set interface interface="Ethernet" metric=15, and netsh int ipv6 set interface interface="Ethernet" metric=15 for the second family, since int ip touches IPv4 only.

The binding order is the last resort rather than the first move. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage holds a Bind list of device identifiers, and moving the tunnel identifier to the front does change which adapter is asked first, but it is a machine-wide registry value with no per-namespace scope. Export it before editing, and reconnect the tunnel afterwards so the order applies in the state the client expects.

For a single namespace, prefer the narrower instrument:

Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServers

Decision three: does the fix survive a reconnect?

A metric that works until the next dial-up reconnects was never persisted. L2TP/IPsec and other connection profiles are recreated when the connection starts, so the stored value lives in the phone-book entry as IpInterfaceMetric, not only on the live interface. Some environments script that field for exactly this reason; others push the preference from management policy and leave the endpoint alone.

Cache and registration are a separate layer. Running these after the tunnel comes up fixes stale entries and re-registers the client, but neither reorders an adapter:

ipconfig /registerdns
ipconfig /flushdns

There is an off switch in the same layer. Disabling dynamic registration on the physical adapter stops the client advertising its VPN-side address under the wrong name, which is a different repair from the refresh above.

IPv6 deserves its own line in the decision. If the physical adapter holds a global IPv6 address while the tunnel carries IPv4 only, Windows can prefer the untunneled path for name resolution. Check that family separately, because a metric set for IPv4 says nothing about it:

Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetric

Disabling IPv6 on the LAN adapter removes that path and the protocol with it; a metric change on the IPv6 interface, or an NRPT rule for the corporate namespace, keeps the family and fixes the preference. Choose the narrow one unless you have decided that link should not have IPv6.

Verify with the source named, and keep one owner

Verify with tools that report which source is in effect, not merely whether a page loads:

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type A

Then separate filtering from selection, because they look identical from an application. OpenVPN's block-outside-dns blocks port 53 on other adapters; it does not choose a resolver. If every query now fails, a filter may be blocking the only reachable server; if the configured resolver is being ignored, the order or the namespace rule is wrong. Changing both at once makes a blocked query and an ignored query indistinguishable.

Keep one owner for DNS policy: the VPN profile, a management policy, or an NRPT rule, not two of them. Before you close it out:

• The pushed resolver answers when named explicitly, and an ordinary lookup uses it.
• The rule or metric you changed covers the address family that actually carries the queries.
• The setting survives a disconnect and reconnect, or you have moved it into the stored profile.
• Exactly one mechanism is authoritative, and the others were left as they were.

Treat the order as environmental state rather than a thing you finish. Recheck it after a reconnect and after a Windows update that touches the network stack, because either one can put the physical adapter back in front.