ClusterXL Failover Drops Remote Access and Site-to-Site VPN
A healthcare provider runs a two-member R81.10 ClusterXL cluster in High Availability mode. Member A is active, member B standby. The cluster supports 2,500 Remote Access VPN users and a site-to-site VPN to a partner. The sync network is 10.0.0.0/30 on eth3. During a planned failover test, member A was rebooted. All VPN users disconnected, and reconnection took eight minutes. Logs show IKE phase 1 retransmits and a cluster failover event. cphaprob stat shows member B active. cphaprob -a if shows the sync interface on member A as down before the reboot. The site-to-site tunnel also failed with no matching SA after failover. The partner's encryption domain is 172.16.0.0/16; the local encryption domain is manually defined as 192.168.0.0/16 plus the cluster VIP. The business requires sub-minute failover for VPN.
1. Why did failover drop all VPN sessions, and what ClusterXL checks come first?
Read the worked answer
The sync interface being down before the reboot is the key clue. In ClusterXL High Availability, the standby member needs the connection table and cluster state to take over cleanly. If state synchronization is broken, failover is cold: existing VPN and site-to-site flows have no synchronized state, so they drop and clients must rebuild IKE and IPsec from scratch. Eight minutes is consistent with IKE retransmits and client retry timers, not a fast stateful failover.
Check the cluster state first with cphaprob stat, then inspect interface monitoring with cphaprob -a if. Confirm that the sync network is up on both members, is not routed through an external or NATed path, and is permitted by the underlying network. Use cphaprob syncstat to see synchronization status and counters. Verify that both members run the same policy and that the sync interface is not shared with production traffic or oversubscribed.
Do not treat the failover itself as the root cause. Fix the sync link first, then retest failover with a canary VPN user before involving the remote-access clients or the partner.
2. What VPN and cluster settings reduce reconnect time and preserve site-to-site traffic?
Read the worked answer
Make the cluster VIP the stable VPN endpoint. In Link Selection, use the cluster VIP as the primary address and configure a backup path if one exists. Ensure the VPN community and remote-access clients use the DNS name that resolves to the VIP, not a physical member address. Enable IKEv2 where supported and dead peer detection so clients detect a dead peer faster and reconnect to the active member.
Verify that the cluster object is configured to synchronize the state needed for VPN, and that both members have identical VPN communities, encryption domains, and certificate trust. If the platform does not preserve IKE SAs across failover, plan for fast reconnection rather than seamless session preservation: shorten client retry timers where the client supports it, keep the VIP stable, and test that the client can reconnect to member B without manual intervention.
For site-to-site traffic, confirm that the partner peers to the VIP and that the local encryption domain includes all internal subnets behind the cluster plus the VIP. Avoid NATing VPN traffic unless it is explicitly designed. Reinstall policy to both members after any VPN or cluster change, and retest failover with a single test tunnel before the production partner tunnel.
3. How do you diagnose the no matching SA error after failover?
Read the worked answer
Start with the negotiation, not the data path. On the cluster, enable IKE debugging for the partner IP and reproduce the failover or clear the tunnel. Check whether phase 1 completes and phase 2 fails, or whether phase 1 itself fails. The no matching SA message usually means the responder cannot find a phase 2 selector that matches the proposed traffic, or the proposal/encryption domain does not match.
Compare the local manually defined encryption domain with the partner's configured domain. The local domain must include every local subnet that will be tunneled and must not include translated public addresses unless NAT is intended. Confirm that the partner's 172.16.0.0/16 matches what the local side expects and that no overlapping internal subnet exists. Check the VPN community's encryption methods and shared secret or certificate trust on both members.
Use fw monitor on the cluster to confirm that IKE and ESP traffic reaches the active member and that return traffic leaves the same path. Verify Link Selection uses the VIP so the partner sees a stable peer address after failover. If the partner uses the old member address, update the peer configuration or DNS. Fix the selector or peer address, clear the tunnel, and test with a single host before restoring all traffic.