IPsec Tunnel Up but Only One Subnet Flows
Two sites run strongSwan 5.9 on Debian 12: HQ uses 10.10.0.0/16, and the branch uses 10.20.0.0/16. The branch is behind carrier-grade NAT (CGNAT). IKEv2 with certificate authentication is established, and the tunnel stays up. HQ users can reach 10.20.1.0/24 and 10.20.2.0/24. Branch users can reach 10.10.5.0/24 but not 10.10.6.0/24. Small HTTPS requests work, but large transfers through the tunnel stall. ping -M do -s 1400 fails from branch to HQ, while ping -s 1200 succeeds. The branch's external address occasionally changes. StrongSwan logs show CHILD_SA rekeying every 30 minutes, and users report brief outages after idle periods. Firewall rules are present on both sides, but no one has reviewed the traffic selectors or MSS handling since the tunnel was built.
1. The tunnel is up, but branch users cannot reach 10.10.6.0/24. What do you inspect, and what are the likely causes?
Read the worked answer
Start with the CHILD_SA traffic selectors, because an established IKE SA does not prove that every subnet is covered. Run swanctl --list-sas on both peers and compare each CHILD_SA's local and remote traffic selectors with the intended /24s. If 10.10.6.0/24 is missing from remote_ts on the branch or from local_ts on HQ, the packet will not match an IPsec policy. Check ip xfrm policy and ip xfrm state on both ends, then use ip route get 10.10.6.5 from the branch to see whether the route points into the tunnel.
Likely causes are an omitted traffic selector, a separate CHILD_SA that is not up, a missing return route on HQ, or a firewall rule that allows 10.10.5.0/24 but not 10.10.6.0/24. Also check reverse-path filtering and any NAT rule that hides branch traffic. Use tcpdump on both tunnel endpoints while pinging a host in 10.10.6.0/24: if packets enter the tunnel but never appear on the HQ internal interface, the problem is on the HQ side; if they never enter the tunnel, fix the branch selector or route.
2. Large HTTPS transfers stall while small requests work. Diagnose the MTU/MSS problem and propose a fix that works through CGNAT.
Read the worked answer
The symptom is classic path-MTU failure. IPsec ESP adds overhead, so the tunnel's usable MTU is below 1500. If the branch or CGNAT blocks ICMP Fragmentation Needed, the sender never learns to reduce its packet size, and large TCP segments are dropped. The successful ping -s 1200 and failed ping -M do -s 1400 support this. Confirm with tracepath or repeated ping -M do sizes, and capture TCP retransmissions during a stalled transfer.
The robust fix is MSS clamping on the TCP SYN packets that traverse the tunnel, for example an iptables/nftables mangle rule using TCPMSS --clamp-mss-to-pmtu, or a strongSwan connection setting such as mss = 1360. Clamp on both sites if either side may originate large flows. Also set the tunnel interface MTU consistently and verify that the firewall permits the necessary ICMPv4 type 3 code 4 messages where possible. Do not simply lower the MTU on all host interfaces; that affects unrelated traffic and does not fix forwarded TCP sessions.
3. The branch is behind CGNAT and the tunnel drops after idle periods. Which strongSwan settings and operational checks address this?
Read the worked answer
CGNAT devices expire UDP mappings, so a site-to-site tunnel needs keepalives and a rekey interval shorter than the mapping timeout. Enable NAT-Traversal encapsulation with forceencaps = yes, configure keep_alive and dpd_delay so traffic refreshes the mapping, and set IKE and CHILD_SA lifetimes so rekeying happens before the CGNAT idle timer expires. If the external address changes, enable MOBIKE where supported and use dynamic DNS or a stable rendezvous point so the peer can be found again. Verify that both peers agree on the encapsulation and that no firewall blocks UDP 4500.
Operationally, monitor IKE SA and CHILD_SA state, not just interface status. Log rekeying and DPD events, and test after 15 to 30 minutes of idle time. Confirm that the CGNAT mapping timeout is longer than the keepalive interval; if it is shorter, reduce the interval. Distinguish an IKE SA outage from a CHILD_SA outage, because the fixes differ: IKE problems usually involve UDP 500/4500 and identity, while CHILD_SA problems usually involve traffic selectors or rekey timing.