IPsec Dial-Up and SAML Fail During FGCP Failover
A company runs two FortiGate 100F units in active-passive FGCP HA at its edge. 1,200 remote workers use FortiClient IPsec dial-up to a VIP on the primary, authenticated by SAML SSO against Entra ID with MFA; group membership is passed through a RADIUS server. Session pickup is enabled, but IPsec SA synchronization is not configured. During a planned primary failover, all VPN users disconnect and must re-authenticate. Some then receive 'no response from server' because the secondary cannot reach the IdP. The IdP metadata uses a hostname that resolves only through an internal DNS server reachable over the primary's ISP link. The secondary has the same configuration but a different ISP path. The company requires less than 30 seconds of failover and wants to avoid an MFA prompt storm. The HA heartbeat uses two direct cables; the WAN interfaces are not monitored.
1. Why did all IPsec users disconnect and why did some fail to re-authenticate? Separate HA synchronization, routing/DNS, and SAML causes.
Read the worked answer
Three separate failures. First, FGCP session pickup does not automatically preserve IKE/IPsec state unless IPsec SA synchronization is enabled and working; on failover the secondary has no tunnel state, so all 1,200 clients disconnect and renegotiate. Second, the secondary cannot resolve or reach the IdP because the IdP hostname depends on an internal DNS server reachable only over the primary's ISP link. After failover, SAML authentication fails with 'no response from server.' Third, the MFA prompt storm is a consequence of all users re-authenticating at once; it is not an HA timer problem. WAN interfaces not being monitored also means the cluster may not fail over for a WAN-specific failure, but a planned primary failover would still move the VIP. Check diagnose vpn tunnel list on both nodes before and after failover; if the secondary has no SAs, IPsec sync is the first fix.
2. Design the HA and SAML settings for failover under 30 seconds without creating an MFA prompt storm.
Read the worked answer
Enable IPsec SA synchronization/session pickup for IPsec in the HA configuration and verify it, rather than assuming session pickup covers it. Make the IdP reachable from both units independent of the primary's ISP: use DNS servers reachable from both WAN paths, or a public FQDN with a public IP, and a source NAT/route that exists on both nodes. If the IdP requires a stable source IP, use a separate NAT address per node or a shared VIP, and test both paths. For SAML, set a consistent source IP where FortiOS supports it and ensure the SP metadata/return URL uses the HA VIP, not a node-specific address. Keep MFA, but reduce the storm with IdP session lifetime, FortiClient 'remember me' where policy allows, and staged reauthentication; do not disable MFA. Tune HA timers and link monitoring so failover is under 30 seconds, and test with real tunnels.
3. What would you test in a maintenance window, and what evidence proves the VPN actually survives failover?
Read the worked answer
Test with at least 20 active IPsec tunnels and a mix of SAML users. Record get system ha status, diagnose sys ha status, diagnose vpn tunnel list, and SAML/IdP logs on both nodes. Trigger a controlled primary failover, then measure: tunnel count on the secondary, time until FortiClient passes traffic, whether users see an MFA prompt, and whether new authentications succeed. Capture traffic on the secondary's WAN path to the IdP. A successful test shows existing tunnels surviving or re-establishing without full reauthentication, new SAML logins succeeding via the secondary, and no authentication timeouts. If tunnels still drop, do not declare success based on HA status alone; the VPN state is the evidence.