FortiExpert logoFortiExpert
Sign in
← Back to knowledge base
highVPN (IPsec / SSL)

Troubleshooting IKEv2 dial-up IPsec VPN debug output and client access on FortiOS 7.2.8

Confirmed 8/8/2026

Problem

An IKEv2 dial-up IPsec VPN using the NCP VPN client for Windows does not operate as expected after migration to a FortiGate. Packet captures confirm that client traffic reaches the FortiGate, but the IKE debug displays only blank lines. In some cases, phase 2 SA and TSi establish correctly, but the client still cannot access the internal network.

Symptoms

IKE debug output is empty even though packets reach the FortiGate. Alternatively, the phase 2 SA and TSi are established, but VPN client traffic does not pass to the internal network.

Environment

FortiGate configured for an IKEv2 dynamic dial-up IPsec VPN on port10, using mode configuration, AES256-SHA256, DH group 14, peer ID matching, split tunneling to "INTRANET Subnet", and the NCP VPN software client for Windows. The reported phase 1 configuration included DHCP address assignment.

FortiOS version

7.2.8

Root Cause

The IKE log filter was applied with the wrong address: the FortiGate WAN IP was used with the destination-address filter instead of the remote user's public IP. A separate traffic-flow problem was caused by missing firewall policies. The reported setup also found that IKE mode configuration did not work with DHCP as configured and required an Address Group instead. Another possible issue is a DHCP server that is not set to "type ipsec"; a missing route to the remote network can also prevent full VPN operation.

Solution

  1. Clear any existing debug session before starting a new capture.
diagnose debug disable
  1. Filter the IKE debug by the remote peer's public IP address. For dst-addr4, use the public IP of the user PC attempting to connect—not the FortiGate WAN IP.
diagnose vpn ike log-filter dst-addr4 [remote-peer]
  1. Enable timestamps in the console output.
diagnose debug console timestamp enable
  1. Enable detailed IKE application debugging.
diagnose debug application ike -1
  1. Start debugging and reproduce the VPN connection attempt.
diagnose debug enable
  1. Stop debugging after collecting the negotiation output.
diagnose debug disable

  1. If the VPN does not establish completely, verify that the firewall policy and the route to the remote network exist. If DHCP is used, verify that the DHCP server is set to type ipsec.

  2. If phase 2 SA and TSi are established but client traffic cannot reach the internal network, add or correct the required firewall policy rulesets.

  3. Review address assignment. In the reported configuration, IKE mode configuration did not work together with DHCP as configured; selecting an Address Group resolved that part of the setup.

  4. If the tunnel is established but traffic still does not flow, inspect session processing with flow debug. Obtain the required filters and output parameters from the applicable flow-debug KB article.

diag deb flow

Verification

Reconnect the NCP VPN client and confirm that the IKE debug now shows phase 1 and phase 2 negotiation messages. Verify that the phase 2 SA and TSi are established, an appropriate client address is assigned, and the client can access the permitted internal network through the configured firewall policy and route.

Tags

No tags yet.

Community rating

— / 5 (0)

Discussion (0)

    No comments yet.