LAN Hostname Fails Over VPN: Suffix, mDNS or Zone?
A short name can rely on a search suffix, a .local name on multicast, and a company name on a private zone. A route alone supplies no naming service.
Beside the device, the printer answers to a short name and the file server answers to a nickname. Through the tunnel, both names time out while their addresses still work. The route is doing its job; the naming path that made those short names work never crossed the tunnel. Three mechanisms produce that behaviour, and each one needs a different correction.
Start by identifying which mechanism the name depends on.
Three Kinds of Name That Behave Differently
A single-label name such as fileserver usually relies on a DNS search suffix appended by the resolver. That suffix often arrives with the local DHCP lease, so a remote client obtaining addressing from the VPN has no reason to know it. Adding a route does not deliver the suffix. The short name simply stops existing as a name, even though the address behind it is reachable.
A name ending in .local is normally resolved by multicast DNS on the local link, as RFC 6762 describes. Multicast does not cross a routed tunnel unless something deliberately bridges or proxies it, so the name stops resolving the moment you leave the segment.
A fully qualified company name belongs to an internal zone served by the organisation's resolvers. That one works remotely when the VPN pushes those resolvers and the client is configured to use them. And localhost is special-use per RFC 6761: it refers to the machine in front of you, never to a remote service.
Read the Resolver Before Changing the Route
Ask which name server answered and which suffix was appended. The same query through different resolvers gives different answers, and that difference is the evidence you need.
getent hosts fileserver getent hosts fileserver.corp.example.com nslookup fileserver.corp.example.com dig +search fileserver A resolvectl query fileserver.corp.example.com scutil --dns | head -30
If the fully qualified query resolves but the short one does not, the failure is a suffix, not a server. If neither resolves and the address works, the client is not using the internal resolver at all. Compare the resolver list with what the VPN is supposed to push, because a client that keeps its local resolver for every query will never see the internal zone.
Bring the Right Name to the Client
Ask the administrator for the documented remote-access name, in full, and use that in the profile instead of guessing suffixes. If the deployment supports split DNS, configure the internal domain to be resolved by the internal servers while everything else keeps the local resolver. Push the search domain through the VPN configuration where the client supports it.
Verify the result on the client rather than on the gateway. A setting applied on the server that never reaches the client changes nothing.
Keep Certificate Identity Intact
An address-based test that ignores the certificate error proves only that the socket opened. The service certificate is issued for a name, and the client will keep refusing the mismatch for good reason. If the certificate lists only the internal name, use that name and fix resolution, or obtain a certificate that covers the address you intend to use.
Record the name, the resolver and the suffix that produced a successful connection. That record saves the next person from repeating the address-based workaround which hides the real problem.