mDNS Inside a VPN: Why .local Names Do Not Resolve

Your office printer appears in every application at your desk and vanishes on the VPN, even though you can ping the address you know it has. Nothing in the tunnel is broken: discovery and reachability are separate services, and only one of them crosses a routed tunnel by default. The checks below separate them before you start adding routes. A route cannot fix a query that never left the link.

Check what resolves today, and what only looks resolved

Separate the two questions first: a unicast query for a hostname asks a resolver, while a browse for _ipp._tcp asks the local link. On Linux, avahi-browse -a shows what multicast DNS can see, and resolvectl query name.local shows what the resolver stack does with that name. On macOS, dns-sd -B _ipp._tcp lists discovered services without needing an address first.

If the address answers and the name does not, routing works and discovery does not. A .local name can also be answered on the host itself through nss-mdns without avahi-browse being installed, so a successful getent or ping to that name is not evidence that discovery crossed the tunnel; the browse result and the resolver result are different pieces of evidence. Applications cache what they discovered, which is why the failure often appears hours after connect rather than at connect time. Quit and reopen the application, then check whether the cached entry holds a name or an address, because an address keeps working long after discovery stopped.

Why the query never crosses the tunnel

Multicast DNS sends queries to 224.0.0.251, inside the local network control block, on UDP port 5353. Routers do not forward addresses from that block, so the query stays on the link it was sent to. Senders also set the IP TTL, or the IPv6 hop limit, to 255 so that a receiver can reject a packet that already crossed a router, which is how the protocol detects off-link spoofing rather than how it stays local. Locality comes from the destination address, not from a one-hop TTL.

The tunnel type matters as well. A tun-style interface carries IP packets and nothing else, so no multicast group survives it. A tap-style bridge extends the broadcast domain itself, which is why some legacy designs bridged instead of routing, and inherited every problem bridging brings.

A trusted-LAN exception does not change any of this, because it decides which traffic may use the tunnel rather than teaching the tunnel to forward multicast. The packet still has no shared segment to be heard on.

Choose a naming design you can support

For company resources the durable answer is a routed hostname served by the resolver the VPN pushes, with split DNS so internal names go to internal servers and everything else does not. Windows exposes that as a name resolution policy table, macOS uses scoped resolvers per interface, and most clients have an equivalent push setting. The device keeps its normal name in internal DNS, and discovery stops being part of the path.

A discovery proxy or an mDNS reflector can bridge the gap, and it is a real design with its own host, its own exposure and its own client requirements. It does not appear because you added a route. Never forward .local queries to a public resolver: the domain is reserved for local multicast use by RFC 6762, and sending it outward produces slow failures and needless data disclosure.

Verify the service, not the name

A name in a browse list proves the discovery step, not that the service answers. Open the print queue or the web interface and complete a real operation, then repeat it after a reconnect.

Discovery caches names aggressively, so a stale entry can look like success. If a certificate or authentication prompt appears, that is the next layer and a separate problem. Write down which mechanism you changed, resolver or discovery, so the next person does not relitigate the whole question.