Ping Is Not Proof: Test the Path Between Two Sites

The tunnel is up, the gateways answer each other, and the users at one site still cannot open the file share at the other. Someone pings from the gateway, gets a reply, and declares the network healthy. That reply travelled between two devices that were never the problem. A useful test starts at the host that needs the service, uses the protocol the application uses, and reproduces the condition under which it fails. Everything else is a green light for a path nobody is on.

Start at the client that needs the service

Write down four things before testing anything: the client address, the destination address, the hostname and the application port. Then confirm the service works locally at its own site, from a host next to it. Without that baseline you cannot distinguish a broken tunnel from a broken service, and half of these tickets are the second one.

Try the documented hostname and, where the service permits it, a direct-address check of the same port. A failed name lookup and an unreachable resolved address send you down different paths. If you substitute an IP for a hostname, do not disable the HTTPS identity check to make it work; a certificate warning is information, not an obstacle.

Walk the path at each edge

Read the route the client selects, then the route the gateway selects for that destination, then the counters or a scoped capture at each edge. You are looking for two facts: did the request arrive on the remote LAN, and did a reply come back. Interface counters include every other flow, so correlate by exact timestamp and address pair rather than by graph shape. A capture taken at the wrong edge is worse than none, because it looks like evidence.

ip route get 10.10.0.5
sudo tcpdump -ni any host 10.10.0.5 and port 445
sudo tcpdump -ni any net 10.10.0.0/24 and net 10.20.0.0/24

If the request appears on the remote edge with no reply behind it, the problem is on the far side: a firewall, a missing return route, or a host that does not accept the source. If the request never appears, the local route or the tunnel selectors never carried it, and the far side is not yet worth investigating.

Use the protocol the application uses

ICMP is a weak probe. It can be filtered, rate-limited or handled by a different policy than the service, which makes both its success and its failure ambiguous. Test the actual port and, where you can, the actual protocol handshake.

nc -vz 10.10.0.5 445
curl -sv --max-time 5 https://files.corp.internal/ -o /dev/null
openssl s_client -connect 10.10.0.5:443 -servername files.corp.internal

A completed TCP handshake proves reachability and policy for that port. It does not prove the application works: authentication, an upload or a specific API call can still fail. Test the operation users actually perform, using a harmless equivalent rather than repeatedly submitting a real transaction.

Reproduce the condition that fails

Failures that appear only with large transfers are a size problem, not a connectivity problem. Send a large packet with the don't-fragment bit set and watch where it stops. If a small request succeeds and a large one hangs, the tunnel MTU and the MSS handling at the gateways are the next suspects.

ping -M do -s 1400 10.10.0.5
ping -M do -s 1472 10.10.0.5
curl -sS --max-time 30 -F file=@./sample.bin https://files.corp.internal/upload

If only one subnet fails, look at traffic selectors, route advertisements and that subnet's return gateway. If only the hostname fails, follow DNS, including which resolver the client used and whether the remote view is visible from that site. Three different failures, three different fixes, and the ping test distinguishes none of them.

After the fix, repeat the same test

Re-run the identical client, destination, port and payload. Then reconnect or exercise the failover path if the design has one, because a fix that only works while the original tunnel instance is alive has not been tested. Keep the test tied to a real source, a real destination and a real operation rather than one green indicator on a dashboard.

Record the four baseline values and the result. The next report of the same symptom can then start from evidence instead of from a ping.