← Back to knowledge base
mediumVPN (IPsec / SSL)

Troubleshooting intermittent IPsec dial-up VPN disconnections

Confirmed 8/8/2026

Problem

An IPsec dial-up user experiences intermittent VPN disconnections. Troubleshooting requires synchronized packet captures and debug logs from both FortiGate and the affected FortiClient host to identify where and why the tunnel is interrupted.

Symptoms

The FortiClient IPsec dial-up tunnel disconnects intermittently, frequently goes down, or experiences slowness. Relevant evidence may appear in FortiGate VPN Events, FortiClient endpoint logs, packet captures, or DoS anomaly logs.

Environment

FortiGate and FortiClient versions 7.2 and 7.4. Packet capture and debug collection require a remote terminal client such as PuTTY, Wireshark on the affected host, and access to FortiGate logs. FortiGate-to-FortiClient compatibility must be confirmed in the applicable release notes.

FortiOS version

7.2 and 7.4; the IKE address-filter command changes starting with v7.4.1.

Root Cause

The precise cause must be established from synchronized captures and logs. Possible factors include incompatible FortiGate and FortiClient versions, NPU offload behavior, Phase 2 settings without Autokey Keep Alive, or a DoS policy on the VPN-bound interface incorrectly classifying IPsec traffic as a threat. If no packets appear in the FortiGate sniffer, NPU offload may be preventing traffic from being visible to the capture.

Solution

  1. Prepare persistent PuTTY logging. Open a PuTTY session to FortiGate and configure it to retain the output for later analysis. In PuTTY, go to Category > Logging, select All Session output, and choose the folder and file in which to save the session log. Use PuTTY rather than the FortiGate GUI CLI for long debug sessions because the GUI output can have incorrect formatting or the session can time out.

  2. Start a FortiGate packet capture. Replace the placeholder with the public IP address of the affected host:

diagnose sniffer packet any " host <PublicIP of the Host getting disconnected> and port (500 or 4500) " 6 0 l

Run the packet capture and debug session at the same time. If the sniffer displays no packets, temporarily disable npu-offload under Phase 1. Guidance is available in Disabling NP offloading for individual IPsec VPN phase 1s.

  1. Capture traffic on the affected host. Install Wireshark on the remote host and start a packet capture with a filter for the relevant IPsec signaling traffic. Select the interface through which VPN signaling traffic is sent. The source does not provide the capture-filter text.

  2. Collect FortiGate IKE and authentication debug output. In the same logged PuTTY session, run:

diagnose vpn ike log filter clear
diagnose vpn ike log filter rem-addr4 <PublicIP of the Host getting disconnected>
diagnose debug console timestamp enable
diagnose debug application ike -1
diagnose debug application fnbamd -1
diagnose debug enable

The timestamps help isolate events when the known date and time of a disconnection are available. The IKE address filter limits output to the affected host. Starting with v7.4.1, diagnose vpn ike log filter dst-addr4 was changed to diagnose vpn ike log filter rem-addr4; use the command appropriate for the installed version.

  1. Stop collection immediately after reproducing the issue. Press Ctrl+C to stop the FortiGate sniffer. Then stop and reset debugging:
diagnose debug disable
diagnose debug reset
  1. Convert and analyze the captures. Convert the FortiGate sniffer output to PCAP by following How to import diagnose sniffer packet data to Wireshark. After capturing a disconnection successfully, follow Decrypt ESP packets to decrypt the ESP traffic. Correlate FortiGate and host captures by timestamp.

  2. Review FortiGate VPN events. In the FortiGate GUI, go to Log & Report > System Events > VPN Events. Examine entries around the exact time of the disconnection for the termination reason and related events.

  3. Collect FortiClient debug logs. Before attempting another VPN connection, enable the VPN module and select the debug log level in FortiClient. For complete endpoint-log analysis, use the FortiClient run diagnostic tool. For configuration details, refer to How to enable debug log in FortiClient or, for EMS-managed endpoints, How to enable debug log level on FortiClient endpoints managed by EMS.

  4. Verify firmware compatibility. Check the relevant release notes to confirm that the installed FortiGate and FortiClient versions are supported together. For FortiClient 7.4.7, use Product integration and support.

  5. Test without NPU offload. Because inbound IPsec traffic is normally offloaded to the NPU and this can sometimes contribute to disconnections, temporarily disable NPU offload under the affected Phase 1 and attempt to reproduce the issue. Use the individual Phase 1 procedure linked in step 2.

  6. Check Phase 2 behavior. If the tunnel frequently goes down, inspect its Phase 2 settings and enable Autokey Keep Alive. See Using IPsec auto-negotiate and keepalive.

  7. Inspect DoS policy processing. If a DoS policy exists on the specific interface to which the dial-up IPsec VPN is bound, verify its configuration. In the GUI, go to Log & Report > Security Events > Anomaly logs and determine whether the policy is incorrectly treating VPN traffic as a threat, which can cause intermittent disconnections or slowness. Supporting references are DoS policy on WAN interface can cause slowness and Denial of Service anomalies explained.

Verification

Reproduce the connection under observation and confirm that the tunnel remains stable. Correlate FortiGate sniffer output, Wireshark traffic, IKE and fnbamd debug messages, FortiGate VPN Events, FortiClient diagnostic logs, and Anomaly logs at the same timestamp. If testing a specific mitigation, verify stability after confirming version compatibility, disabling NPU offload temporarily, enabling Phase 2 Autokey Keep Alive, or correcting a DoS policy that was matching VPN traffic.

Rollback

After the capture or isolation test, stop and reset FortiGate debugging with diagnose debug disable and diagnose debug reset. If NPU offload was disabled only for testing, restore the original Phase 1 NPU-offload setting after evidence collection. No other rollback procedure is provided.

Tags

No tags yet.

Community rating

/ 5 (0)

Discussion (0)

    No comments yet.