Why name lookups fail over a routed OpenVPN tunnel

A host answers ping by address and fails every lookup by name. The tunnel is up and the route exists, so the natural conclusion is that the VPN is misconfigured. A more useful conclusion is that the lookup was never routable: a routed tunnel carries unicast IP, while the query in question was a broadcast looking for a segment that does not exist on the other side. Once the layer mismatch is visible, the fixes sort themselves by cost.

Myth: the tunnel is broken because names fail

The symptom is convincing because everything above the name layer works. Addresses route, the interface is up, and the peer answers a ping. What failed is a discovery mechanism that never had a path across a point-to-point link, and that is a different statement from a broken tunnel. Separating those two statements is most of the diagnosis.

Treating it as a tunnel fault leads to profile edits that cannot help. Adding options, changing ciphers or reinstalling the client leaves the broadcast exactly where it was.

Name the mechanism that failed before naming the fix. A lookup that uses broadcast needs a segment, while a lookup that uses a resolver needs an address to ask.

What TUN does and does not carry

A TUN device is an IP interface, which is what makes it routable. OpenVPN hands the client an address and a set of routes, and from then on the client sends datagrams to a peer. Nothing in that model creates a shared link where every host hears every frame.

Discovery traffic does not fit that model at all. Older Windows name queries, SSDP announcements and mDNS requests are sent to everyone on a segment rather than to one destination. A routed link has no everyone to send to. Every one of those mechanisms assumes a shared medium.

The tunnel can therefore be healthy while discovery fails completely. That sentence is the one to hold on to when someone reports the VPN as down.

Bridging works by removing the boundary

A TAP device carries frames, and a bridge attaches it to a real LAN segment. The client then holds an address on that segment and hears its broadcast traffic. That is why bridging appears to cure the name problem. It also makes the client depend on that segment for addressing.

The cure is removal of the routing boundary, not any new naming ability inside the tunnel. Everything the segment broadcasts now crosses the link as well.

For a small lab that is a fair trade. Across a distributed workforce it rarely is.

Pushing DNS and WINS is the narrower repair

Give the client somewhere specific to ask. dhcp-option DNS and dhcp-option DOMAIN point internal names at a server that knows the zone, and a Windows client still relying on NetBIOS can receive a WINS server the same way. The tunnel stays routed and the segment stays where it belongs.

Two conditions decide whether that works. The named server must answer for the zone, and the query must be permitted through the tunnel.

Test the resolver from the client rather than from the server's own shell. A resolver that works locally says nothing about what the tunnel carries.

Find out which layer failed

Ping the address first, then resolve the name and read which server replied. A negative answer from a server that does not host the zone looks different from a query that never left the machine. A name that resolves but refuses connections is a third problem entirely.

Multicast sits behind the same wall. A group such as 224.0.0.251 is not forwarded across a routed tunnel by default, and a route for the group is not enough without a multicast-aware path or a reflector on the LAN.