Internal names fail on VPN while public sites resolve fine

One user reports that the intranet hostname does not resolve over the VPN. A second report, from the same laptop, says a leak test still shows queries answered by the local resolver. They sound like one problem and are two, with different evidence, and the usual repair for the first makes the second worse. Separate them before touching a setting.

Two symptoms that are not one fault

Failing to resolve an internal name means the question went somewhere that has no answer for it. Queries leaving the tunnel means the question went to the wrong place even when the answer was available. Those are opposite failures: one is a missing answer, the other is an extra destination.

The trap is that adding the office resolver everywhere fixes the first and guarantees the second. Adding a public resolver everywhere does the reverse.

Write both observations down with a timestamp, then work through the four checks below in order.

Which adapter's resolver gets the question

On Windows, the DNS client chooses servers according to the adapter binding order, and the tunnel adapter is not automatically first. Open the adapter's advanced settings and move the remote access connection above the physical adapter, then reconnect so the change applies to a fresh session.

Binding order is only the first half. The client also has to know which names belong to that adapter, and that is a suffix question rather than an ordering question.

Put the working machine's ipconfig /all next to the laptop's, both taken while the tunnel is up. The working machine will show a connection-specific DNS suffix on its office adapter, and the laptop may show none on the tunnel. That difference explains a whole class of "the server is right there and the name still fails" reports, because without a suffix the short name is never completed into the zone the office resolver serves.

A short name needs a suffix before it needs a route

Typing an unqualified hostname asks the resolver to guess a domain. The guess comes from the suffix list attached to the connection, and if that list is empty the query goes out as a single label that no private zone will match.

Copy the working machine's suffix into the VPN adapter's IPv4 properties on the DNS tab, then reconnect. On Linux the equivalent is the search domain on the tunnel link, which systemd-resolved exposes per link rather than globally.

Keep the two settings separate in your notes. A suffix changes what is asked; the resolver address changes who is asked. Fixing one while the other is wrong produces a result that looks random.

Ask the resolver directly, then the name

A direct query to the office resolver separates a name problem from a path problem, because it bypasses the client's resolver selection entirely.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

The first command asks a specific server for a fully qualified name. If it answers, the resolver and the route to it are fine and the fault is in selection or suffix. If it times out, the address is wrong or unreachable and the problem is routing rather than DNS. The second command shows what happens with the short name, and the third prints the per-link resolver configuration on a systemd host.

Watch for wildcard answers, which some networks return for unknown names. A reply that looks plausible is not proof that the intended server answered, so compare the returned address with the one the internal service actually uses. If the address belongs to a parking page or a proxy, the resolver answered but the answer was never yours. That distinction saves an hour of chasing a tunnel that was working the whole time.

On Linux, a VPN client that rewrites /etc/resolv.conf replaces the local resolvers entirely. vpnc exposes DNSUpdate no to stop that, and systemd-resolved can route only the listed domains to the tunnel link. Both approaches keep public names on the local resolver while sending internal names to the office.

Leaks are a rule, not a checkbox

Name resolution is a UDP exchange to port 53, so a tunnel that carries web traffic but not UDP leaves the query on the physical path. Prove it by capturing on the physical NIC while a public name is resolved. A query visible on that interface in readable form means the tunnel is not carrying it.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

If the query appears on that interface in readable form, the tunnel is not carrying it. The repair is a rule that permits port 53 only to the resolver the VPN pushed and drops other destinations, plus a client configuration that does not silently discard the pushed option.

That last part matters more than it looks. Start OpenVPN with route-nopull and the pushed DNS option disappears along with the routes, unless the pull filter is widened to keep it. and a client that ignores dhcp-option DNS will keep using whatever it had before. Any change on the server side needs a fresh session to take effect, since the resolver list is delivered when the tunnel comes up and a stale session keeps showing the old state.

Record which failure you actually observed before closing the ticket. A missing internal answer and a query escaping the tunnel call for different repairs, and a suffix change that fixes the first can quietly worsen the second. Whoever picks up the ticket next will trust the label, so make the label accurate.