Diagnose routes, DNS, and MTU

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

The same IP works on one network but not another

That is the signature of an address 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 instead of the tunnel.

Ask the kernel which way a packet would go:

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. Renumbering the company range is the permanent fix, and nobody wants to do it, which is why the collision keeps coming back.

An IP works but a private hostname fails

Routing is fine. Name resolution took the wrong path. Ask who answered:

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. Compare the SERVER line in the dig output with the resolver you configured. If they differ, fix the resolver settings, not the routes.

Small requests work but larger transfers stall

The login page loads and the download freezes. That is MTU territory. Don’t touch application code. Test packet sizes instead:

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. Try 1400, then 1350 or 1425, and so on. Then compare the boundary with the tunnel interface’s MTU. If the boundary is lower than the MTU, some link on the path is smaller than the tunnel thinks, and the tunnel MTU needs to come down to match.

Write the expected path first

Before running any of the commands above, write one sentence describing what should happen. Something like: “packets to 10.0.1.100 leave via the tunnel, and names resolve at 10.0.1.53”.

Then compare the route table, the dig output, and the logs with that sentence. Each command either confirms a piece of it or contradicts it, and a contradiction tells you exactly where to dig.

Without the expected picture, every command output looks plausible. Debugging degrades into running commands and hoping. With it, the three patterns above become a checklist you can walk in five minutes.