Diagnose routes, DNS, and MTU

Three failure patterns cover most VPN support tickets. Learn their shapes and you diagnose in minutes what others chase for hours.

Pattern one: the same private IP works on one network but not another. That is the signature of an address overlap. Compare local and tunnel routes for overlap — the hotel Wi-Fi happens to use the same range as your company, and longest-prefix matching hands your packets to the local network:

ip route get 10.0.1.100
# 10.0.1.100 via 192.168.1.1 dev wlan0 src 192.168.1.34
# a physical interface answered — the tunnel never saw this packet

When the output names a physical interface instead of the tunnel, the local network won the routing decision. The fix is a more specific tunnel route, or moving to a network that does not collide.

Pattern two: an IP works but a private hostname fails. Routing is fine; name resolution took the wrong path. Inspect DNS resolver policy and query logs:

dig wiki.internal
# status: NXDOMAIN   ← a public resolver answered; it has never heard of this name

resolvectl status
# check which DNS server each interface is actually using

NXDOMAIN from a public resolver means your queries are not reaching the private DNS server that knows the name.

Pattern three: small requests work but larger transfers stall. The login page loads and the download freezes — that is MTU territory. Test packet sizes and inspect MTU rather than changing application code:

ping -c 1 -M do -s 1300 10.0.1.100   # replies arrive
ping -c 1 -M do -s 1450 10.0.1.100   # silence: the path limit sits between the two

Narrow the range until you find the boundary, then compare it with the tunnel interface’s MTU.

Write down the expected path before debugging: one sentence like “packets to 10.0.1.100 leave via the tunnel, names resolve at 10.0.1.53”. Then compare the route table and logs with that picture. Without the expected picture, every command output looks plausible, and debugging degrades into running commands and hoping.