VPN Connected but One Service Fails: Isolate the Stage

Connected is the least informative fact in a VPN ticket. It records that two peers finished a handshake and nothing about the name that was queried, the interface the packet left through, its size, or whether the far end accepted it. That is why one service can fail while every other application on the same laptop works. Walk the stages in order and the first failing one names the fault.

Start With the Name, Not the Tunnel

Resolve before you route, because a bad answer makes every later test meaningless. Query the name with the system resolver and compare that answer with the address the application actually used. A private name that comes back as a public address means the query went to a resolver with no business answering it. A name that fails to resolve is the same category, only louder.

resolvectl query host.internal
getent hosts host.internal

Browsers with their own secure-DNS setting fail here while the rest of the system works. That is why a browser-only complaint belongs at this stage first, before anyone touches a route. Compare both commands rather than one, since getent follows the NSS path and the resolver query does not.

Ask the Kernel Which Path It Chose

The routing table is a preference order, and the path the kernel picks is not always the one the diagram shows. Ask it directly for the destination in question. The reply names the interface, the next hop and the source address that will be used. A packet can leave through the tunnel carrying a source address the far side refuses, and a more specific entry in the physical table can send it out of the Wi-Fi interface instead.

ip route get 10.20.30.40
ip -brief address show

Read the dev, via and src fields in that order, because each one eliminates a different suspicion. This stage also owns state the client installed, since firewall rules and routes can persist after an abnormal exit. That is why no internet without the tunnel and no internet unless the client runs are one family of fault rather than two.

Probe the Packet Size

A tiny reply that comes back while a bulk transfer stalls points at the path MTU first. One probe with the do-not-fragment bit set, sent from inside the tunnel, separates this stage from the rest. Raise the payload until the probe fails and you have the number that matters.

ping -M do -s 1400 10.20.30.40

Small probes succeeding while a directory listing or an upload hangs is the signature of this stage. The complaint sounds like credentials or a firewall rule, and it is neither.

The number is a property of the path rather than the client, so a value that works on an office connection can fail on a mobile link. Keep the probe command with the ticket, since the next person needs the same measurement. If a smaller payload passes, the fix is a clamp or a lower tunnel MTU, not a new cipher.

Test the Far Side

Test the destination by its address, then look at what is listening there. A connection refused and a connection that never answers are different findings. The first says something is up and not serving that port, and the second says nothing came back at all. Neither is a client problem by default.

curl -sv http://10.20.30.41:8080/health
nc -vz -w 3 10.20.30.41 3389
ss -lnt 'sport = :8080'

Nothing reachable through a tunnel can be a service listening only on 127.0.0.1, because the listener never sees the packet. When the far host's firewall allows the office subnet and refuses the tunnel pool, the result looks like a client fault and is not one. Remote desktop or file sharing breaking while web traffic survives usually lands here, however the user phrased it.

Map the Complaint to One Stage

Most reports collapse into one of five shapes, and each shape names a stage. One site that works only through the tunnel is a name answer or a policy tied to the source address. Updates failing without the tunnel while browsing works is a name or route problem for that client.

Everything stopping when a provider client starts is installed state, which is a route and firewall question. One service unreachable while the rest is fine is the far side. Transfers stalling a few seconds in is packet size. Match the shape before running commands, because it decides which evidence to collect first.

Record the stage that produced the first failure along with the command output. A ticket that says the source address was wrong, with the route line attached, is worth acting on, while one that reports the VPN as broken is not.