VPN works but internal names use the wrong DNS · Linux Fix Lab

Symptoms & scope

Public hostnames resolve while the VPN’s internal fully qualified names fail.
A private DNS server is present but its expected routing domain is missing or shadowed.

Relevant environment

NetworkManager VPNs with systemd-resolved or another split-DNS-capable plugin; plain resolv.conf cannot express the same per-domain routing.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

The VPN may omit a route-only domain, use an unintended ~. catch-all domain, or lose selection through DNS priority settings.
The internal server may lack an IP route through the VPN; .local names also need explicit design because resolved normally treats that suffix as multicast DNS.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Read DNS servers and routing domains after the VPN is active. Compare its link with the physical network without changing resolver state.

resolvectl status

Interpret the result: A ~corp.example domain routes that suffix to its link; the most specific matching suffix wins. ~. is a wildcard and can intentionally or accidentally capture unrelated queries.

Check 2

Replace VPN_PROFILE with the saved VPN connection name. Read both families’ DNS policy without displaying credentials or activating the VPN.

nmcli -f ipv4.dns,ipv4.dns-search,ipv4.dns-priority,ipv4.ignore-auto-dns,ipv6.dns,ipv6.dns-search,ipv6.dns-priority connection show "VPN_PROFILE"

Interpret the result: The active resolver result can include server-pushed values beyond the saved profile. A negative DNS priority can exclude other connections with greater numeric priority; compare all active profiles before adjusting it.

Check 3

Replace DNS_IP with the confirmed private DNS server’s address; use ip -6 route get for IPv6. This calculates a route without sending a probe.

ip route get DNS_IP

Interpret the result: The selected device and gateway should match the intended VPN path. Correct domain selection cannot compensate for a route that sends the private server outside the tunnel.

Evidence-guided next steps

Attach the intended private DNS domain

If the VPN is missing its administrator-specified routing domain, save the profile and add only that suffix as a route-only DNS domain, such as ~corp.example after replacing the example with the real domain. Reconnect the VPN and compare an internal fully qualified name.

Precautions: Use ~. only when the VPN is intentionally responsible for all DNS. Preserve required search domains and any managed corporate profile that will overwrite local edits.

Recovery / rollback: Restore the saved DNS domain list and reconnect the VPN if public or private queries are routed incorrectly.

Did this solution help you?

Share this solution #

Align DNS priority with the server route

If the intended VPN DNS is excluded by a confirmed priority conflict, adjust only that profile’s DNS priority according to the network policy. If route lookup instead misses the tunnel, correct the VPN’s specific route to the private DNS server or its approved subnet.

Precautions: DNS priority and IP route metrics solve different selection problems. Avoid changing all default routes or leaking internal lookups to a public server.

Recovery / rollback: Restore the saved priorities and specific route list, then reconnect the VPN from a working network path if either address family regresses.