IKEv2 Tunnel Flaps with a Third-Party Peer
HQ runs an R81.10 ClusterXL HA pair with a /16 internal network and three /24 DMZs. A new branch uses a Cisco ASA 5525-X and needs access to two HQ DMZ subnets and one branch subnet. The branch also uses 172.16.0.0/16, which overlaps HQ's lab network. The tunnel is domain-based, IKEv1, and has worked for two weeks. During the migration to IKEv2, the tunnel drops every 30 minutes; vpn tu shows phase 2 rekey failures, and the ASA logs 'no matching child SA'. The Check Point log shows 'IKE: no matching proposal' but only for the overlapping /16. The customer wants a single resilient tunnel, IKEv2, and no route leaks into the lab. No dynamic routing is allowed on the ASA. There is 40 ms RTT and no packet loss.
1. What are the two independent causes of the flapping, and how do the logs distinguish them?
Read the worked answer
The first cause is an IKEv2 child SA proposal or lifetime mismatch. A 30-minute drop is a rekey event, not a random outage. If the ASA initiates rekey at 1,800 seconds and Check Point expects a different lifetime, encryption algorithm, integrity algorithm, or PFS group, the rekey fails and the child SA is deleted. The ASA logs 'no matching child SA'; Check Point logs 'no matching proposal' during rekey.
The second cause is the overlapping 172.16.0.0/16. The branch's local subnet and HQ's lab network are both in the encryption domains. When the ASA proposes a child SA for 172.16.0.0/16, Check Point can match it to the lab network or reject it as ambiguous. The clue is that the proposal error appears only for that /16, while the DMZ subnets rekey normally. The flapping is therefore a combination of a rekey mismatch and a duplicate encryption-domain selector, not a routing or ISP issue.
2. How would you fix the overlapping subnets without re-IP and without dynamic routing?
Read the worked answer
Translate the branch's duplicate range at HQ before it can conflict with the lab. Create a manual NAT rule on the cluster that matches VPN traffic from the branch 172.16.0.0/16 and translates it to a unique range such as 10.200.0.0/16. Match the VPN community in the original packet so lab traffic is not translated. Add static routes for 10.200.0.0/16 toward the VPN and for the HQ DMZ subnets toward the branch. Do not add a route for the branch's real 172.16.0.0/16 into the HQ routing table.
Update the VPN encryption domain and the peer's interesting traffic to use the translated branch range, or use VPN NAT so the ASA sees the translated selectors. Keep the lab 172.16.0.0/16 out of the tunnel domain. For resiliency, use one route-based VTI tunnel with static routes rather than many domain-based subnet pairs; this gives a single tunnel and avoids rekeying multiple child SAs. No dynamic routing is required on the ASA, only static routes for the translated prefix and HQ DMZs.
3. What IKEv2 settings and verification steps would you standardize to prevent the rekey failure from returning?
Read the worked answer
Standardize the IKEv2 proposal and child SA settings on both peers: AES-256, SHA-256, DH group 19, PFS enabled, and the same child SA lifetime on both sides. Do not rely on defaults when interoperating with a third-party peer; confirm the ASA's crypto map lifetime and Check Point's phase 2 lifetime match. If lifetimes cannot match, configure the shorter lifetime on both sides so rekey is predictable.
Verification: run vpn tu during a rekey and confirm the child SA is replaced without deletion; check ASA show crypto ikev2 sa and Check Point IKEv2 debug for proposal matching; confirm the selector is 10.200.0.0/16, not 172.16.0.0/16. Use fw monitor to verify NAT occurs before encryption and that no lab route is preferred. Test a controlled cluster failover and a rekey under load. Rollback is to the previous IKEv1 tunnel only if IKEv2 cannot be stabilized, but keep the NAT change because it fixes the overlap independently.