Ping From the IPsec Gateway Uses a Different Source Address

Ping the far side from the IPsec gateway, get no answer, and conclude the tunnel is broken, while every workload behind the gateway is passing traffic normally. The two results are not contradictory. A ping started on the gateway is a locally sourced packet, and the gateway chooses a source address from its own routing table. That choice can differ from the addresses real site traffic uses, which changes which policy matches and which return route applies. Decide what the test is meant to prove before you read anything into its result.

Three different questions a ping can answer

The first question is whether the remote end is reachable at all from this host. The second is whether the tunnel's selectors or route-based policy admit traffic from a particular source. The third is whether forwarded traffic from a workload behind the gateway works end to end. One command cannot answer all three, and the source address is what separates them.

Pick the question first. Otherwise a failed ping becomes evidence for whichever theory you already had.

Why the gateway picks an address you did not expect

When you ping a destination, the local stack chooses a source from the route that matches it. On a route-based tunnel that can be the link address of the tunnel interface, which in many site designs is a 169.254.x.x pair chosen for the point-to-point hop. Those addresses exist to make the link work; they are not advertised as application-source networks on the far side.

So the remote end may receive an echo request from an address it has no route back to, or one that no selector matches. The tunnel can be healthy and the ping can still fail, which is exactly the false negative this article is about.

Choose the source deliberately

On a controlled Linux gateway, select a source that is already assigned locally: ping -c 4 -I 10.30.0.1 10.40.0.20. The addresses here are illustrative, so substitute the gateway's real inside address and a real remote destination, and confirm that the source you pick belongs to this device and is admitted by the site policy.

Do not borrow a workload's address for the test. Impersonating a host that is not assigned to the gateway creates a result nobody can reproduce, and on some stacks it fails in ways that look like a tunnel fault.

Read the reply path, not just the request

Check which source actually arrives at the remote destination, including any deliberate translation on the way. Then check the remote side's route back to that source and the selectors or policy that permit it. A request that arrives with an unexpected source is a routing and policy question, not a cryptographic one.

This is also where a capture helps more than another ping: it shows the source the far end saw, which is the address its reply has to reach.

Then test the workload

The decisive test is a ping from an ordinary host behind the gateway to an ordinary host behind the remote gateway. That exercises the gateway's forwarding role, the real application source and the true return path, which is the flow users care about.

Keep the results separate in your notes: gateway-local reachability, policy admission for a chosen source, and forwarded traffic. A successful pinned ping is useful evidence that the tunnel carries something; it is not proof that every forwarded flow works. And an automatically chosen gateway source that cannot be reached is not proof that the site tunnel is down.

Do not add a blanket route for 169.254.0.0/16 just to make one diagnostic answer. That trades a misleading test for a permanent routing decision, and the next person inherits it without the context.