VPN Connected but Names Fail: Where DNS Actually Breaks

Tunnel up, icon green, and every browser tab reporting a name-resolution failure. Three different mechanisms produce that picture: the resolver may be unreachable, the client may be asking a resolver you did not expect, or only the private names may be failing. Separate them before you change anything about the tunnel protocol, because each one is repaired in a different place. The order below starts with the observations that split the three apart.

What a lookup actually needs

A lookup needs three things: a resolver address, a route to that address, and an answer that matches the question. Each can fail on its own, and the visible symptom is the same page that does not load. That is why the error page tells you almost nothing until you know which of the three broke.

The client learns its resolver from the VPN profile, from DHCP on the tunnel, or from its own configuration, and which source wins depends on the platform. On Windows, ipconfig /all prints the DNS servers per adapter, so you can see whether the pushed value actually arrived. A pushed value that never reached the operating system is a quiet and common failure. Read the configured value before you touch the profile.

Linux and macOS answer the same question with different commands, and the answer deserves the same reading: resolvectl status and scutil --dns both list the servers per interface. Compare that list with the address the profile claims to push. A mismatch here explains everything downstream, so settle it before you test names.

Test one public name and one private name

Query an ordinary public hostname and the documented private hostname from the same machine, and record which server answered each one. If both fail, the resolver or its route is broken. If only the private name fails, the resolver answered and the question becomes the zone or the routing. Run the two queries within a minute of each other so a route change cannot explain the difference.

Keep internal names out of public screenshots and out of public resolvers. A timeout and a nonexistent-domain answer are different observations: the first says nothing came back, the second says an authority replied that the name does not exist. Treating them as one error sends you to the wrong layer, and a certificate warning is a third thing again rather than a DNS failure.

nslookup prints both the server it asked and the reply it received, which is exactly the pair you need. Run it twice from the same shell and write the responding address beside each answer.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Confirm the client can actually reach that server

A private resolver pushed by the profile is only useful if the client can reach it while the tunnel is up. A correct-looking address with no route produces a timeout, and the connected state of the tunnel says nothing about that route. The check is a route lookup aimed at the resolver itself, not at the VPN endpoint.

Each platform answers that in one line, and the interface named in the output is the whole answer. If it points at the physical adapter while the resolver sits behind the tunnel, the profile is not pushing a prefix that covers it.

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

On a split-tunnel profile the resolver can sit outside the pushed routes, which is a profile problem rather than a server problem. Compare the resolver address with the pushed prefixes and confirm that one of them covers it. The same mismatch explains why DNS works on one network and fails on another with an identical profile.

Remember that browsers can bypass the system resolver

A browser with secure DNS enabled can send queries over HTTPS to a provider of its own choosing and ignore the operating system's resolver entirely. The system then looks correct while the browser fails, or the reverse. That is a policy question for the browser, not for the tunnel.

Check the browser's secure-DNS setting and any managed policy that controls it, then try a second application or browser with the tunnel unchanged. If only one application fails, the fix belongs in that application. A private window is not a clean comparison, because it may disable extensions by default in one browser and not in another, and it never bypasses managed policy. Use a second browser profile or a different application instead.

Flush the cache and retest the real task

After correcting a setting, flush the local resolver cache so an old answer does not outlive the fix. A brief recovery followed by another failure means the cause is still present, not that the flush failed. Pick the line that matches the machine you are on, because the three caches are separate.

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

Then repeat the original task rather than a synthetic lookup, because the task is what the user cares about. Reconnect once as well, so the retest covers the state the user will actually be in. Microsoft's nslookup reference is the page to keep for the query arguments.

If names fail only after disconnecting, the client did not restore the previous configuration, which is a lifecycle bug to report rather than a DNS server to replace. A working lookup is also not a leak test, since the exit country tells you nothing about which resolver answered.