pjhtech Tools
FortiGate

FortiGate IKE Debug Shows No Output

Check VDOM, inherited filters, log-filter versus log filter syntax and whether a negotiation is actually starting.

A stale IKE debug filter can hide the tunnel you are testing. Clear that filter, set the observed peer address and enable IKE debug in the tunnel’s VDOM. Then connect the VPN client or observe a rekey: a new TCP connection through an established VPN does not necessarily start IKE.

Scope: FortiGate CLI; filter one IPv4 remote gateway.

Use the tunnel’s VDOM and the correct filter syntax

Run the commands in the VDOM that owns the tunnel. A global administrator on a multi-VDOM unit enters config vdom, then edit "<existing-vdom>"; use end after the investigation. Read show vpn ipsec phase1-interface there and find the tunnel’s interface and remote-gw. Use the remote address observed on the WAN, including upstream NAT. IKE filters can persist across CLI sessions: inspect the current filter before replacing it.

Read-only • current syntax
diagnose vpn ike log filter list

FortiOS 7.4.1 changed log-filter to log filter and dst-addr4 to rem-addr4. On older builds use diagnose vpn ike log-filter list. This syntax difference is why otherwise valid examples can be rejected.

Clear the old filter and capture this peer

Replace 198.51.100.20 with the remote gateway. Debug output may contain identities and key material; keep the capture private.

Diagnostic state change • FortiOS 7.4.1+ syntax
diagnose vpn ike log filter clear
diagnose vpn ike log filter rem-addr4 198.51.100.20
diagnose debug application ike -1
diagnose debug console timestamp enable
diagnose debug enable

On older builds, use diagnose vpn ike log-filter clear and diagnose vpn ike log-filter dst-addr4 198.51.100.20 for the first two lines.

For a disconnected remote-access client, select Connect in its VPN client. For a site-to-site tunnel with no matching SA, send traffic covered by its selectors. If the required SAs are already established, observe the next rekey instead.

Confirm whether IKE packets arrive

In a second CLI session in the same VDOM, capture the peer’s UDP 500/4500 traffic during that VPN connection attempt or rekey. Replace the peer address:

Diagnostic capture • stops after 20 packets; Ctrl+C stops it sooner
diagnose sniffer packet any 'host 198.51.100.20 and (udp port 500 or udp port 4500)' 4 20 l

The interface and in/out markers show where each packet arrived or left. Outbound requests without replies point to peer delivery or response, while inbound requests with silent IKE debug point back to the VDOM/filter or local handling. UDP 4500 also carries encapsulated ESP, so seeing that port alone does not establish a new IKE exchange. If no packets arrive, stop with Ctrl+C; the packet limit is not a timer.

Read-only • run in the tunnel’s VDOM
get router info routing-table details 198.51.100.20
diagnose vpn ike gateway list

If the gateway list already shows an established IKE SA, wait for its rekey to observe a new IKE exchange. Correct a peer route selecting the wrong egress. For a missing protected-data route, use the subnet routing and policy fixes.

Still no output?

If the sniffer shows inbound UDP 500/4500 but IKE debug remains silent, compare the packet’s destination with the tunnel’s interface and local-gw. Check whether a VIP redirects those ports using the interface, VIP and IP-pool checks. For traffic addressed to the FortiGate itself, inspect the receiving interface’s local-in rules. Keep the same observed peer address in the debug filter while retrying.

Stop and clear the diagnostic state

Cleanup • use log-filter clear on older builds
diagnose debug disable
diagnose debug application ike 0
diagnose debug console timestamp disable
diagnose vpn ike log filter clear

Restore any filter needed by another active investigation. diagnose debug reset also resets other debug settings, so it is broader than this cleanup.

References