IKEv2 Tunnel Flaps After PPPoE Migration
Acme Manufacturing runs a Cisco Secure Firewall 2130 HA pair at HQ and an FTD 1140 at a branch. The site-to-site IKEv2 tunnel uses two ISP links with BGP and ECMP, NAT-T enabled, DPD 10 seconds with 3 retries, IKEv2 rekey 86400 seconds, and IPsec SA lifetime 3600 seconds. After the branch moved to PPPoE DSL, the tunnel drops every 9 to 14 minutes and then recovers on its own. Small pings and BGP hellos traverse; SMB transfers stall and trigger retransmits. Logs show Duplicate Phase 2 SA and occasional DPD R-U-THERE timeouts. Branch MTU is 1492 and HQ is 1500. The branch default route alternates because of BGP, and return traffic sometimes arrives on the other ISP. The team disabled fragmentation inspection as a test; drops decreased but did not stop. Management wants the tunnel stable within one maintenance window and no new hardware.
1. The tunnel establishes and passes small packets, then drops every 9 to 14 minutes. Which failure modes fit the evidence, and what specific checks would separate them?
Read the worked answer
Three modes fit, and they are not mutually exclusive:
- Path MTU black hole. The branch moved to PPPoE at 1492 while HQ is 1500. Small pings and BGP hellos pass, but SMB large segments stall. Disabling fragmentation inspection reducing but not eliminating drops is consistent: it removes one drop path without fixing PMTU.
- DPD and rekey interaction. DPD 10 seconds x3 on an ECMP path can declare a peer dead during loss, and a 3600-second IPsec lifetime does not match a 9 to 14 minute cycle. However, Duplicate Phase 2 SA suggests overlapping rekeys caused by lost DELETE or Notify messages.
- Asymmetric routing. BGP ECMP can return traffic on the other ISP, so stateful inspection and NAT-T see different flows, followed by DPD R-U-THERE timeouts.
Separate them with size-specific tests: ping -M do -s 1400 and -s 1472 across the tunnel. Capture on both FTDs and look for ESP versus ICMP need-frag. Check show crypto ikev2 sa and show ipsec sa timestamps for overlap. Correlate syslog drop times to rekey and DPD timers. Trace the return path with route lookup and packet-tracer. Prove whether large packets or state loss precedes the drop before changing DPD.
2. Recommend a stable configuration and operational design. Justify each change against the observed symptoms rather than listing commands.
Read the worked answer
Set a defensible MTU/MSS baseline and remove multi-path ambiguity:
- Clamp TCP MSS on both tunnel interfaces to 1360, or 1380 where PPPoE overhead is 8+20+8, and permit ICMP type 3 code 4 on the outside ACL so PMTUD can work. This directly addresses large-packet stalls while leaving small control traffic intact.
- Stop ECMP for the tunnel. Use one active ISP with a floating static or BGP local preference and hold the second as standby. Asymmetric ESP is a stronger explanation for mid-flow state drops than rekey alone.
- Tune DPD to about 30 seconds with 5 retries for WAN jitter, add IKEv2 SA lifetime jitter, and keep the IPsec SA lifetime slightly shorter than IKEv2 to avoid overlap. Enable NAT-T keepalives. This targets the Duplicate Phase 2 SA and R-U-THERE evidence.
- Remove fragmentation inspection only after MSS clamping is proven, not as the primary fix.
Validate in one window: transfer 100 MB with the DF bit set, poll show crypto ikev2 sa every 5 minutes for 24 hours, and confirm no duplicate SPI or DPD timeout. If drops persist, capture at both edges and verify CPE MTU and carrier NAT idle timers.