Why Equal-Cost Routes Make VPN Faults Hard to See
When several tunnels share a cost, each flow can take a different one. A successful ping says nothing about the path your application actually uses.
A user reports that the internal application works from one machine and fails from another, and the ping you run from the gateway succeeds either way. With several tunnels of equal cost, that is not a contradiction. Each flow is placed on a next hop, so your probe and the user's session may simply be using different paths. The walkthrough below reproduces the choice before changing anything.
One ping, several possible paths
When a route has more than one next hop at the same cost, the router has to pick one per packet. Most implementations hash fields from the packet, typically the source and destination addresses together with the protocol and ports, so responses stay on the same path. Different applications, or even different connections from one application, produce different hashes.
That is why a diagnostic from the gateway proves so little. The gateway's own probe has its own addresses and ports, and therefore its own hash. It may land on the healthy tunnel while the user keeps landing on the broken one.
How the platform picks a next hop
Reproduce the choice instead of guessing it. Ask the kernel which route it would use for the same source and destination as the failing session. That lookup includes fields a plain destination lookup ignores. Run it from a working client as well, and compare the two answers:
ip route get 10.20.5.7 from 10.20.0.14Newer iproute2 releases also accept the protocol and destination port, which matters when the hash includes them. Compare that output with the same lookup from a working client and the difference is the evidence you were missing.
| Observation | Likely cause | First check |
|---|---|---|
| Ping works, application fails | A different flow hash selects another tunnel | Per-flow lookup from the client's address |
| Some users fail, others do not | One tunnel lacks a prefix or selector | Compare both tunnels' installed routes |
| Fails only at larger sizes | Tunnels have different effective MTU | Probe the same size over each path |
| Fails after a reconnect | Stateful asymmetry between paths | Session state on both gateways |
Walk the failing flow, not the route table
The route table lists both tunnels and looks correct by definition. The question is what each tunnel does with the packet once selected. Verify that both carry the same protected prefixes, the same forwarding permission and a return path that reaches the same client.
Pay attention to stateful devices in the middle. If a request leaves through one tunnel and the reply returns through the other, a firewall or NAT that never saw the original flow will drop it. The two tunnels each forward traffic correctly, and the connection still fails.
Also check the MTU per path. A path with an extra encapsulation shrinks the usable size, and a transfer that succeeds on one tunnel stalls on the other at exactly the size where the smaller one breaks.
Compare one path at a time
Where the design allows maintenance, take one tunnel out of service and repeat the user's task. If the failure disappears, the problem belongs to the path you removed, and the next step is to compare its configuration against its neighbour rather than to re-examine the routing table.
Compare the real application, not repeated pings. Record whether the failure follows a particular next hop, a packet size or a transition after reconnect, because those three patterns point at different repairs.
Finally, write down why the paths are considered equivalent and how a failure is supposed to remove one from service. Multipath is only safe when the paths really are interchangeable, and that is a design statement worth checking rather than assuming.