VPN Hostnames Fail, IP Addresses Work: Where to Look

You can open the share by address and the same share by name fails, which means the tunnel is carrying packets and the naming layer is not. That single observation saves a detour through firewall and route changes. Names need a suffix, a resolver and a path for the query, and a VPN client can install a route without installing any of them. Walk the four checks below in order and stop at the first one that breaks.

A name asks a question an address does not

An address is a destination the stack can use immediately. A short name is a question that has to be expanded with a suffix, sent to a resolver and answered by something that knows the zone. A tunnel that installs routes but no resolver leaves the first working and the second broken. That is why the symptom looks so consistent across very different VPN products.

Work outward from the address: first the full name, then the bare hostname, and note which of the three works. The pattern tells you which layer to inspect before you open a single configuration screen. Guessing at routes when the FQDN resolves is wasted effort.

Read the resolver the tunnel actually installed

Ask the operating system which resolver handles queries for the internal zone, not which one the VPN client's interface advertises. A server that pushes a public resolver with no internal zone produces exactly this failure, and it is a configuration error rather than a routing fault.

resolvectl status
nslookup fileserver.corp.example
nslookup fileserver

On a domain-joined Windows client the namespace routing policy decides which queries go to which resolver, and the VPN adapter's own DNS settings appear in the adapter details. Read the effective policy rather than the profile, because a cached policy can outlive the connection that installed it. If the resolver answers the FQDN and not the short name, the problem has already moved to the suffix list.

Get-DnsClientNrptPolicy
ipconfig /all

Stop if the internal zone resolves through the right server. The resolver is not your problem.

Suffixes explain short names that fail

A single-label name is expanded with the connection's suffix list before the query is sent. If the VPN does not deliver the internal suffix, fileserver never becomes fileserver.corp.example, and the query goes out as a name no public resolver knows. Pushing the suffix, or typing the full name, tests the hypothesis without changing anything on the server.

nslookup fileserver.corp.example
ping -a 192.168.50.20

On Linux the resolver service ties a DNS server to a link and a set of routing domains, so a pushed server that is not associated with the tunnel's link behaves as if it were not there. Check the per-link status rather than the stub file, which may only point at the local resolver. The same split appears in the other direction: a search domain that is present but not applied to the tunnel interface produces short-name failures that look random.

If adding the suffix fixes it, the remaining work is to deliver that suffix through the VPN profile instead of asking every user to type it.

NetBIOS and WINS are a different mechanism

Legacy SMB can still look up a bare name with NetBIOS name service, which answers over broadcast or through a WINS server. Broadcast stays inside one broadcast domain and stops at the first router, so it cannot reach across a tunnel; WINS works because the client has a unicast address to register with and to query. That is why a VPN carrying only IP can still support legacy names when WINS is configured and reachable.

nbtstat -n
nbtstat -R

For modern SMB, rely on DNS and the full name, and retire the legacy path. If it is genuinely legacy, provide WINS or replace the application; the middle ground is a support queue that never empties.

The walkthrough ends when you can say which layer failed: resolver, suffix or legacy discovery. Record the resolver that answered and the name form that worked, because the next person will start from the same symptom.