VPN Took Over DNS and Broke Local Names: Fix the List

The tunnel comes up, the intranet loads, and the printer's name stops resolving. Or the reverse: local names still work while everything inside the corporate network times out. Both symptoms come from the same place, a resolver list that the VPN client rewrote when it connected.

Repair the list deliberately, then deal with the push mechanism separately. Routes are a third topic and not the one being fixed here.

Which list applications actually use

Windows resolves through interface-level settings rather than through whatever a dialog shows, so start with the effective per-interface lists. The alias matters more than the display name, because every command below addresses an interface. Get the alias wrong and the repair lands on the wrong adapter. It will appear to work until the next reconnect, when the tunnel's own entry returns.

The question is which servers ended up in front, and whether they arrived as static entries or as a DHCP lease. Both facts decide which repair is available to you.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Read the output for the tunnel adapter and for the physical one, and note every address on each. A static entry can be removed by a policy or a script; a DHCP-provided one is bound to the lease and will return, which changes the repair you should choose. Names in the remote network resolve from the advertised resolver, names on the local LAN from the physical one, and the query goes to whichever list is consulted first.

Remove the pushed servers, or rank them lower

Delete the pushed servers when nothing inside the tunnel needs them, because the physical adapter's own resolvers take over again. Keep them only if the remote network owns zones that its servers alone can answer, and in that case put a local resolver ahead of them. The two commands below cover both choices, so pick the one that matches the situation rather than running both.

netsh interface ipv4 delete dnsservers name="Corp VPN" address=all validate=no
netsh interface ipv4 add dnsservers name="Corp VPN" address=172.16.20.1 index=1 validate=no

Index 1 is consulted first, so the pushed addresses stay available but stop being the default answer for every query. The validate=no flag skips a reachability probe that frequently fails while the tunnel is still settling, so confirm the result with the show command rather than trusting the exit code.

Two limits are worth knowing before you rely on this. Windows will not delete servers that arrived over DHCP through netsh, and those values persist as DhcpNameServer beneath the interface's registry key, so a registry edit is a last resort that has to be rechecked after the next lease. Adapter binding order is also not a dependable ranking mechanism, because a VPN client can insert its own entry at the top of the list.

Where the push can be filtered

A better repair removes the option before it is applied. The Community OpenVPN client can filter a pushed directive by name, which keeps the server's configuration untouched.

pull-filter ignore "dhcp-option DNS "

The trailing space belongs to the match and the filter names the option rather than a server address. If the profile also contains a block-outside-dns directive, removing it changes leak protection rather than name resolution, so decide that separately instead of bundling the two edits.

For a single stubborn hostname, one line in the Windows hosts file is steadier than reordering resolvers for the whole machine. It is also invisible to the next person, so record it wherever the machine's configuration is documented.

Make the repair survive a reconnect

Resolution has to be tested twice, once against a chosen server and once in the form an application uses. That pair separates a resolver-order problem from a server that never answers at all. Skipping the first test leaves the two causes tangled together.

Resolve-DnsName intranet.corp.example -Server 172.16.20.1
Resolve-DnsName printer.lan

Reconnect the tunnel and repeat both commands. Whatever you changed by hand survives only until the next connection, since the client rebuilds its resolver state while bringing the adapter up. Put the netsh lines into the supported connect script for your client, let that script exit successfully, and add a short wait before it runs. A client that applies DNS after the script will overwrite the result either way.

If public names resolve and internal ones still fail after the repair, the resolver list has stopped being the suspect. The query is probably not reaching the server at all, which points at routing or a firewall rule rather than another DNS setting. Record the interface alias and the addresses you settled on, because both differ between machines and neither survives a rebuild on its own.