Kernaali ToolsA silent IKE debug does not prove that the network is dropping packets. First check the selected VDOM, inherited filter and command syntax; then generate traffic that should trigger a negotiation. An established tunnel carrying data may have nothing new to negotiate.
Applies to: FortiGate CLI, IPv4 remote gateway filter. Two separate workflows: FortiOS 7.2.x syntax, including 7.2.13; FortiOS 7.4.4 syntax after the documented 7.4.1 change. IPv6 and GUI diagnostics require their own matching controls.
Validation: documentation-checked on . No device or lab test is claimed. Version references identify the documentation checked, not a firmware upgrade recommendation.
Find the correct diagnostic context
Confirm the running version and the VDOM that owns the tunnel. In a multi-VDOM configuration, select that existing VDOM before inspecting the VPN. Check the tunnel name and actual remote gateway address: an upstream NAT may make it different from the address you expected. Coordinate with other administrators because IKE filters can survive a CLI session and diagnostic state is shared.
Read the current filter with diagnose vpn ike log-filter list on 7.2.x, or diagnose vpn ike log filter list on 7.4.4. Save its values if another investigation needs them. The official IKE troubleshooting KB documents inherited filters; the syntax-change note places the rename at 7.4.1.
Choose exactly one version-specific workflow
The remote address 198.51.100.20 is synthetic. Replace it with the observed gateway. These commands change diagnostic state, not VPN configuration. The all-level debug can include identities and key material; collect briefly in a protected terminal and never post the raw output publicly.
diagnose vpn ike log-filter clear
diagnose vpn ike log-filter dst-addr4 198.51.100.20
diagnose debug application ike -1
diagnose debug console timestamp enable
diagnose debug enablediagnose 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 enableMake one authorized connection from the protected network, or use the tunnel’s normal negotiated bring-up operation during the agreed window. Observe for about 30 seconds, then stop. Do not flush every tunnel or session to manufacture debug output.
Interpret what you actually observed
| Observation | Next check |
|---|---|
| Syntax rejected | Confirm the FortiOS version and CLI help before using another spelling |
| No fresh negotiation; existing SA is up | Use tunnel counters and application tests; IKE debug does not trace all data packets |
| No negotiation and no relevant traffic | Check triggering route/policy, peer destination and underlay reachability |
| Incoming IKE is visible but debug is silent | Check VDOM, active filter, interface binding and any VIP using the IKE destination ports |
| SA_INIT or authentication messages appear | Use their stage and response to narrow proposal, identity or authentication checks |
Do not confuse a missing offloaded data packet in a software sniffer with missing IKE negotiation. The official KB discusses offload visibility separately. Changing offload is not the first step in this workflow.
Stop output and clean up even after failure
diagnose debug disable
diagnose debug application ike 0
diagnose debug console timestamp disable
diagnose vpn ike log-filter cleardiagnose debug disable
diagnose debug application ike 0
diagnose debug console timestamp disable
diagnose vpn ike log filter clearConfirm output has stopped and the filter list is empty, or restore the previously agreed filter values. A coordinated standalone debugging session may also use the documented diagnose debug reset; it resets other debug settings too, so do not run it over another administrator’s investigation. No VPN configuration rollback is needed if you changed only diagnostic state.
Technical references
Found an issue? Send a correction with a reproducible example.