VPN Site Extension: Follow the Return Route Past the Gateway

Traffic from a branch ends on a gateway whose LAN does not contain the application you were asked to reach. The server sits in a second data centre, across an internal link the VPN never configured. Adding another prefix to the near gateway does nothing for that case, because the far gateway is an encryption endpoint rather than the last router. The path needs a route onward, an admission at the far security boundary and a return decision in the destination's own network.

The far gateway is an encryption endpoint

Gateway-to-gateway IPsec protects traffic between two security devices, and the inner addresses travel across that segment encrypted. Beyond the far gateway, ordinary routing takes over, including whatever policy exists between data centres. The protected segment therefore covers part of the journey and not the remainder. Assuming otherwise is how a design ends up with a healthy tunnel and an unreachable application.

Draw the path in three pieces: branch to near gateway, near to far gateway, far gateway to the application. Each piece has its own owner and its own failure mode.

Read both directions of the tunnel policy

A tunnel policy is usually written from the local side's perspective, and that habit is where partial configurations come from. Both peers must list the branch source and the destination as they will appear inside the tunnel, including any translation the design intends. Updating only the near end produces a phase-two mismatch that reads like a routing failure. Compare the two policy sets before touching any route.

Write source and destination as addresses rather than site names. Ambiguity here resurfaces later as a puzzling asymmetry.

Add the onward route and confirm admission

The far gateway needs a route toward the application subnet, and every router between them needs to admit the branch source. Verify what the far gateway actually has instead of what the diagram claims.

ip route get 10.30.5.10 from 10.10.1.50
traceroute -n -s 10.10.1.50 10.30.5.10

The first command reports the egress interface and next hop the far gateway would choose for that source, which is a question a plain routing table cannot answer. The trace shows where packets stop, and a break after the far gateway points at internal transit rather than at the tunnel. When the route exists and traffic still vanishes, capture on the far gateway and read the source address arriving, since an unexpected address means translation is happening somewhere unplanned. All addresses here are placeholders, so substitute the real branch, transit and application subnets.

Test from the branch, then retest the old path

Acceptance needs a real source rather than a probe from the far gateway. Run the check from a branch host and keep the previously working destinations in the same test.

curl -sS -m 5 http://10.30.5.10:8080/health
ping -c 3 10.20.1.1

A response from the application proves the forward path and the return path together, while the ping to the old destination proves the change did not break what already worked. Capture the source address the application logs, because its access rules and any return route must match that value. Where the branch translates before the tunnel, the policy address and the address the application sees differ by design, so record both. Repeat the test after a rekey or a routing change, since these paths tend to be validated once and then forgotten.

Assign an owner to each of the three segments and to the return route inside the destination network. A path with four owners fails in the gaps between them.