Troubleshooting intermittent IPsec VPN disconnections on FortiGate

1. Identify the failure pattern.

   • Regularly timed interruptions usually indicate a lifetime, timeout, or rekey problem.
   • Disconnects during inactivity suggest DPD, keepalive, NAT-state, or idle-timeout behavior.
   • Failures affecting only particular users or locations suggest an ISP or network-path issue.
   • Correlation with specific actions or times can indicate traffic-related triggers.

2. Check Phase 1 and Phase 2 behavior. Phase 1 uses IKE over UDP/500 or UDP/4500 with NAT-T and determines whether the peer is available. Phase 2 carries protected data through ESP IP protocol 50 or NAT-T ESP over UDP/4500. Compare disconnection timing with each phase's lifetime and renegotiation.

3. Review DPD. FortiGate sends R_U_THERE probes after the DPD idle timeout when no traffic is detected. If the configured retry limit is reached without a response, the tunnel is removed. Avoid retry intervals or retry counts that are too aggressive, particularly for residential or other lossy connections.

4. Enable Phase 2 keepalive when an idle tunnel must remain active. Keepalive traffic prevents the tunnel from becoming idle; unlike DPD, it is not merely a peer-health check.

config vpn IPsec phase2-interface
    edit "phase2-name"
        set keepalive enable
    next
end

5. Check IPv4 and IPv6 interaction. A dual-stack client can establish or identify the peer through IPv6 even when the VPN is intended for IPv4, causing peer-ID or routing conflicts. Account for the absence of IPv6 IPsec VPN support in FortiClient (Windows) v7.4.4–v7.4.5 and FortiClient (macOS) v7.4.5.

6. Examine the complete network path. Ask the ISP to investigate shaping or rate limiting of UDP/500 and UDP/4500, intermittent packet loss, NAT translation timeouts, and firewalls or routers that drop ESP packets. These conditions occur outside the IPsec peers.

7. Address idle-state expiration. Intermediate devices can remove idle connection-state entries while the tunnel still appears up. Use VPN keepalives, suitable DPD settings, and application-level keepalives for critical services.

8. Analyze rekey operations. Soft rekey creates new security associations before removing old ones and should provide a seamless transition. Hard rekey removes old SAs first and briefly interrupts connectivity. Capture and decrypt UDP traffic with a sniffer to inspect IKE exchanges for premature tunnel teardown or incorrect rekey parameters such as the wrong Message-ID.

9. Test hardware offloading. Temporarily disable NPU offloading on the affected Phase 1 interface and ASIC offloading on the associated VPN firewall policy.

config vpn IPsec phase1-interface
    edit "tunnel-name"
        set npu-offload disable
    next
end

config firewall policy
    edit "vpn_policy"
        set auto-asic-offload disable
    next
end

10. Inspect DDoS events. Aggressive DDoS thresholds on the WAN interface carrying the tunnel can cause FortiGate to clear the VPN connection. In the GUI, go to Log & Report -> Security Events -> Logs, select Anomaly from the drop-down, and filter on the user's public IP address.

11. Investigate MTU and fragmentation. Oversized packets can fail when NAT devices, firewalls, or intermediate routers discard fragments. The default FortiGate behavior, set honor-df enable, respects the IP Don’t Fragment bit. Lower the tunnel-interface MTU, typically to 1400–1420 bytes, or lower the parent WAN-interface MTU. Configure TCP MSS clamping for TCP traffic and use Path MTU Discovery (PMTUD) so endpoints can adjust dynamically.

12. Use pre-encapsulation fragmentation if intermediate equipment drops fragments. NPU offloading must be disabled for NP6/NP6XL.

config vpn IPsec phase1-interface
    edit <tunnel-name>
        set ip-fragmentation pre-encapsulation
        set npu-offload disable # required for NP6/NP6XL
    next
end

13. Consider changing DF handling only when necessary. Use set honor-df disable only if endpoints cannot receive ICMP fragmentation-needed messages.

14. Validate certificate or PSK authentication. Confirm that certificates have not expired, chain to a trusted CA on both peers, and contain appropriate key usages. Ensure the FortiGate and FortiClient PSKs match exactly. PSK mismatches can appear as silent Phase 1 authentication failures.

15. Review CRL and certificate-authentication settings. Import and configure CRLs, including through FortiAuthenticator or file import where applicable. Confirm that EAP-cert-auth and signature settings match the selected authentication method. If changing between certificate authentication and PSK, review related settings such as set eap-cert-auth and disable conflicting EAP options after the change.

16. Collect diagnostics and apply only the fix matching the observed cause. If the issue remains unresolved, contact Fortinet Support.

Monitor whether the tunnel remains established across idle periods and Phase 1/Phase 2 lifetime boundaries. Use diagnose vpn tunnel list and packet captures to confirm successful fragmentation and traffic flow. For DDoS-related cases, verify that no matching anomaly event appears under Log & Report -> Security Events -> Logs after remediation. For rekey cases, confirm in decrypted IKE captures that replacement SAs are negotiated correctly without premature teardown or an incorrect Message-ID.

If disabling NPU or ASIC acceleration does not change the behavior, restore offloading by reversing the temporary npu-offload disable and auto-asic-offload disable changes. If pre-encapsulation fragmentation or altered DF handling does not resolve the issue, restore the prior fragmentation and honor-df configuration. Exact original values are environment-specific.