Host Reaches the IPsec Peer, the Docker Container Does Not

You ping the remote host from the Linux box and it answers, so the tunnel works. The container beside you still times out, and the natural next step is to restart Docker. A bridge-network container usually starts with a different source address and enters the host through forwarding rather than through the host application's own output path, so the successful test measured a different packet. For a policy-based strongSwan tunnel, an ordinary route toward the remote subnet is not sufficient when the forwarded packet fails to match the installed IPsec policy.

The walkthrough below follows one destination across two sources, reading state before changing anything.

Start from one destination and two sources

Choose a known service by IP first, so you are not debugging DNS at the same time. Record three facts: the container's bridge prefix, the source address of the host request that worked, and the negotiated local and remote traffic selectors for the tunnel. Those three numbers explain almost every case of this symptom.

Then repeat the failed request from inside the container and capture the source it actually uses. If that address is not covered by the local selector, you already know the outcome, and no amount of container recreation will change it.

Read the policies before touching Docker

Read-only host checks cover the routing decisions, the policy database and the rules that select between them:

ip rule show
ip route show table all
ip xfrm policy

The policy listing shows selectors and direction without needing an IPsec state dump full of key material, which is why it is safe to paste into a ticket. Look for a local selector covering the host address but not the bridge prefix. Also check for overlap: a container route that treats the remote destination as local will never produce the forwarded packet you expect, and the tunnel gets blamed for it. Save that listing next to the container's source address, because those two together are the whole comparison.

If the container prefix is missing, stop and decide the architecture before editing anything else. The rest of this walkthrough assumes you have agreed on which source address is supposed to appear on the wire.

Check filtering and translation in order

Docker's Linux bridge firewall can block forwarding independently of IPsec. With the iptables backend, inspect the FORWARD path and the DOCKER-USER decisions, remembering that a rule appended after an earlier verdict may never run at all. The nftables backend integrates differently, so do not create a DOCKER-USER chain merely because an iptables example named it; check which backend your daemon actually uses.

Then check source translation. A broad MASQUERADE rule can turn a packet that previously matched an IPsec selector into one that no longer does, and the failure looks exactly like a routing problem. The strongSwan forwarding guide documents the NAT exemption needed before such translation for traffic already matching a policy.

That exemption is not a way to add an uncovered container source to the tunnel. It only protects traffic that already fits the design, so settle the selector and return-path questions first, then make NAT and filtering agree with the answer. If you find yourself widening the exemption instead, the selector is the thing to change, not the NAT rule.

Then decide routed or translated

A routed container subnet requires both peers to accept that subnet and a remote return path back to it, which usually means a selector change on both ends and a conversation with whoever owns the far side. A deliberately translated design instead has to present an address covered by the policy at the relevant lookup stage, which usually means a narrow, documented rule rather than a default MASQUERADE.

Neither arrangement follows automatically from the host's working tunnel, and choosing between them is a design decision with an owner. Write down which one you picked, because the next engineer will otherwise re-derive it from the firewall counters.

Watch for the hybrid failure too: half the rule set translated and half not, which produces intermittent success that depends on destination port rather than on anything about the network.

Verify with a fresh connection, not a restart

Use a fresh application connection while watching narrow firewall counters and the remote receiver, so each observation has a source. A Docker restart may change rule state and will also disrupt workloads, which costs you the clean signal you were trying to get.

The durable result is four statements you can show: the container source, the matching protected path, permitted forwarding, and a reply that comes back. When all four hold, the container reaches the peer for the same reason the host does.