XFRM Default Route Swallowed IKE and ESP: Keep the Outer Path

Traffic is protected, the tunnel is up, and then it dies at the next rekey. A default through the XFRM interface described the traffic you wanted to protect. It also swallowed the packets needed to keep protecting it.

The two destinations involved are not interchangeable. The routing has to say so explicitly.

Where the Peer Lookup Actually Goes

Record the active rules, the table that holds the XFRM route and the public peer address. Then look at the path the outer connection would take with its real source and mark. A generic destination tells you nothing about that control path. Only the actual source and mark give a useful answer.

A successful initial connection also proves little. The failure often appears after a route installation changes the answer. Startup succeeds, then the first renewal does not.

ip rule show
ip route show table 220
ip -4 route get 198.51.100.44 from 10.40.0.2
ip xfrm policy list

If the lookup for the peer resolves into the XFRM interface, the outer packets are being routed into the tunnel they build. That is the loop, visible in one command.

Exclusion Options on a Modern Gateway

strongSwan's route-based VPN documentation sets out two practical answers. One marks IKE and ESP so the rule pointing at the XFRM table does not match them. The other leaves a peer route or exclusion the lookup can still reach.

Take the one your rule set can express without side effects. A mark is clean when the rest of the stack already uses marks. It is a hazard when the same mask means something else in another rule. Both packet types need the treatment either way.

Marking IKE alone leaves the data packets on the captured path. That produces a tunnel which handshakes and then carries nothing.

The mark is one bit in the packet's fwmark that nothing else on the gateway claims: 0x1 with mask 0x1 is the usual choice, and it has to be set in two places for the exclusion to work. Charon needs it on the IKE socket, and the child connection's inbound and outbound mark settings need the same value so that encapsulated packets leave marked too. A mask of 0x1 rather than 0xffffffff leaves the remaining bits free, which matters when another subsystem already marks packets on the same host. With both set, the rule is written as an exclusion, so marked packets skip the table that holds the XFRM route and fall through to the main table:

ip rule add not fwmark 0x1/0x1 lookup 220 pref 1000
ip -4 route get 198.51.100.44 from 10.40.0.2 mark 0x1

Then read the answer with the mark applied. Without it you inspect the path protected traffic takes, which is the opposite of the question this section asks.

What Automatic Installation Presumes About the Build

Automatic route installation for an XFRM interface depends on the strongSwan version and its configuration. The interface ID, the installed policy and the association all have to refer to the intended objects. A mismatch shows up as a route that quietly points somewhere real.

Copying a table number or a mark mask from another gateway is how collisions start. Check what already uses it first. A collision affects traffic well beyond the tunnel you meant to change, and the symptom rarely points at the copy.

Peer address changes belong in the design. A host route for yesterday's address is not an endpoint recovery plan, while a mark survives that change.

Watch the First Renewal

Check the outer path after the protected routes are installed, not before. Then watch the next renewal and one application exchange. The failure usually appears at that transition rather than at startup.

ip -4 route get 198.51.100.44
sudo swanctl --list-sas
sudo tcpdump -ni any 'udp port 500 or esp'

Removing the protected default temporarily usually restores connectivity. That result is diagnostic, not final.

The goal is a stable split between inner traffic and the outer packets carrying it. Write the chosen mechanism and its table or mark into the gateway notes. The next person to touch the rules will otherwise reintroduce the loop.