FortiGate Debug Commands Guide: Packet Flow & IPsec 2026
FortiGate debug commands
Troubleshooting network connectivity and VPN tunnels on a FortiGate firewall can feel like searching for a needle in a haystack without the right visibility. Fortunately, FortiOS provides a powerful suite of CLI diagnostic tools to trace packets and dissect IKE negotiations in real time. This comprehensive guide breaks down essential FortiGate debug commands for both packet flow and IPsec troubleshooting, giving you the exact syntax, workflows, and error decodes needed to isolate and resolve complex firewall issues with confidence.
SECTION 1 – PACKET FLOW DEBUG
Core Flow Debug Commands
Reset and clean slate — always run this first
diagnose debug reset
diagnose debug disable
Clears all previously set debug filters and stops any running debug output. Never skip this — leftover filters from a previous session will corrupt your output and waste time.
Set the packet filter — what traffic to capture
diagnose debug flow filter addr <ip>Filters trace output to packets involving this IP (source or destination). Without a filter the output is overwhelming on a busy firewall.
diagnose debug flow filter saddr <ip>Filter on source IP only.
diagnose debug flow filter daddr <ip>Filter on destination IP only.
diagnose debug flow filter proto <number>Filter by protocol. 1 = ICMP, 6 = TCP, 17 = UDP.
diagnose debug flow filter sport <port>Filter by source port.
diagnose debug flow filter dport <port>Filter by destination port.
diagnose debug flow filter vd <vdom-name>Filter to a specific VDOM. On single-VDOM units use root.
diagnose debug flow filter negate enableInverts the filter — shows everything except the filtered address. Useful when you want to exclude management traffic noise.
Show the active filter you have set
diagnose debug flow filterPrints the currently active filter parameters. Always verify this before enabling debug — a wrong filter means no output.
Enable function names in output
diagnose debug flow show function-name enableAdds the internal C function name to each output line (e.g. fw_forward_handler, vf_ip_route_input_common). Strongly recommended — without this you only get line numbers, which are meaningless without source code.
Enable console/iteration level output
diagnose debug flow show iprope enableShows the policy check detail — which policy group was evaluated. Helps when a packet hits the right interface but still misses your policy.
Start the trace
diagnose debug flow trace start <count>Starts capturing packets matching your filter. <count> is the number of packets to trace before auto-stopping. Use 100 for testing, 999999 for continuous. Without a count it runs until you stop it manually.
diagnose debug flow trace stopStops the trace without disabling debug entirely.
Enable debug output to console
diagnose debug enableThis is the master switch. Filters and trace start commands do nothing until this is run. Always the last command you run before watching output.
Disable everything when done
diagnose debug disable
diagnose debug flow filter clear
diagnose debug resetRun these in sequence when finished. disable stops output, filter clear wipes filters, reset clears all debug state. Leaving debug enabled on a production firewall wastes CPU.
Reading Flow Debug Output — What Each Function Means
| Function Name | What It Means |
| print_pkt_detail | Packet arrived at FortiOS kernel — shows proto, src/dst IP, interface, tunnel ID |
| ipsec_spoofed4 | Anti-spoofing check for IPsec decrypted traffic — confirms src IP matches the tunnel’s Phase 2 selector |
| init_ip_session_common | New session allocated — shows session ID. If this line is missing, packet was dropped before session table |
| vf_ip_route_input_common | Routing lookup result — shows which gateway and egress interface FortiOS chose |
| __iprope_tree_check | Policy lookup engine running — len=N shows how many policies were evaluated |
| fw_forward_handler | Forwarding policy check result — the critical line. Shows Allowed by policy X or Denied by forward policy check (policy 0) |
| fw_local_in_handler | Packet is destined for the FortiGate itself — evaluated against local-in policies, not forwarding policies |
| npu_handle_session | Packet offloaded to NP (network processor) hardware — normal for high-throughput sessions |
| ip_session_confirm | Session confirmed and installed in session table — traffic will now flow |
| __iprope_check_one_policy | Individual policy being evaluated — appears when function-name debug is on |
| resolve_ip_tuple_fast | Fast-path lookup — session already exists, being matched to existing entry |
Additional Packet Flow Troubleshooting Commands
Check the session table
diagnose sys session listShows all active sessions. Each entry includes src/dst IP and port, policy ID that allowed it, interface pair, byte counters, and TTL. If your flow appears here with counters incrementing, traffic is passing.
diagnose sys session filter src <ip>
diagnose sys session filter dst <ip>
diagnose sys session list
diagnose sys session filter clearFilter the session table before listing — essential on busy firewalls. Always clear the filter after.
diagnose sys session statSummary statistics — total sessions, half-open connections, session creation rate. Useful for spotting session table exhaustion.
diagnose sys session full-statExtended session statistics including memory usage per session type.
Policy lookup — simulate a packet without sending traffic
diagnose firewall iprope lookup <src-ip> <src-port> <dst-ip> <dst-port> <protocol> <src-intf>Tells you exactly which policy would match a given 5-tuple right now. Returns policy ID, action, NAT status. Use this to verify policy matching before live traffic testing.
Policy hit counters — see if policies are being matched
diagnose firewall iprope show 100004 0Shows all policies in group 100004 (the standard IPv4 forwarding group) with packet and byte hit counters. A policy at zero hits when you expect traffic means the flow never reaches it — check routing and interface assignment first.
diagnose firewall iprope show 100004 <policy-id>Shows counters for one specific policy only.
Routing table checks
get router info routing-table allFull routing table. Check this when vf_ip_route_input_common shows an unexpected egress interface.
get router info routing-table details <dst-ip>Shows the specific route chosen for a destination, including the metric, distance, and which interface it exits.
diagnose ip router ospf all enable
diagnose debug enableLive OSPF debug — use only in lab. Shows adjacency events and LSA exchanges.
Interface and ARP checks
get system interface physicalShows physical interface state, IP, speed, duplex, and counters. Confirm the expected egress interface is actually up.
diagnose ip arp listARP table. If the next-hop MAC is missing, traffic will be routed correctly but dropped at L2.
execute ping-options source <interface-ip>
execute ping <dst-ip>Ping from a specific FortiGate interface — tests reachability from the firewall’s perspective, not through it.
execute traceroute <dst-ip>Traceroute from the FortiGate itself.
SECTION 2 — IPSEC DEBUG
Core IPsec Debug Commands
IKE debug — the main IPsec troubleshooting tool
diagnose debug application ike -1
diagnose debug enable-1 sets verbosity to maximum. Shows every IKE message exchanged: Phase 1 proposal, DH exchange, authentication, XAUTH, Mode Config, and Phase 2 negotiation. This is the first command to run when a tunnel won’t come up.
Lower verbosity levels if output is too noisy:
diagnose debug application ike 1Level 1 shows errors only. Level -1 shows everything including raw payloads.
IKE gateway (Phase 1) status
diagnose vpn ike gateway listShows all active Phase 1 SAs. Key fields to read: name, version, established (seconds), IKE SA created/established count. If established count is 0 your Phase 1 has never completed.
diagnose vpn ike gateway list name <tunnel-name>Filter to a specific tunnel.
diagnose vpn ike gateway flush name <tunnel-name>Force-clears the Phase 1 SA and all associated Phase 2 SAs. Use this to force a full re-negotiation after changing Phase 1 parameters.
IPsec tunnel (Phase 2) status
diagnose vpn tunnel listShows all active Phase 2 SAs. Key fields: name, type, proto, inbytes, outbytes, duration. Counters incrementing = live traffic flowing through the tunnel.
diagnose vpn tunnel list name <tunnel-name>Filter to a specific tunnel.
diagnose vpn tunnel flush name <tunnel-name>Clears Phase 2 SA and forces re-key. Use when Phase 2 is up but traffic is not passing — sometimes the SA negotiates successfully but the kernel data path gets stuck.
Flush and bring tunnel back up cleanly
diagnose vpn ike gateway flush name <tunnel-name>
diagnose vpn tunnel flush name <tunnel-name>Run both in sequence — clears Phase 1 first then Phase 2. After flushing, initiate traffic from the client side (or use execute vpn ipsec-sa-rekey on route-based tunnels) to trigger re-negotiation.
Check IPsec SA details including encryption counters
get vpn ipsec tunnel detailsShows verbose SA information including cipher suite in use, lifetime remaining, bytes encrypted/decrypted, and the username if XAUTH was used. The username field is critical — if it shows blank when you expect XAUTH, the group policy will never match.
get vpn ipsec tunnel summaryOne-line summary per tunnel — up/down status, bytes in/out. Good for a quick health check across many tunnels.
ISAKMP (Phase 1) specific debug
diagnose debug application ike 255
diagnose debug enableLevel 255 is the highest verbosity — shows raw ISAKMP payloads. Use only when level -1 isn’t showing enough detail about a Phase 1 failure.
IPsec kernel engine debug
diagnose debug application ikemgr -1
diagnose debug enableikemgr is the IKE management daemon on newer FortiOS builds. Use this in addition to ike debug when tunnels negotiate successfully at IKE level but traffic fails to pass.
Check Phase 1 and Phase 2 configuration quickly
show vpn ipsec phase1-interface <tunnel-name>
show vpn ipsec phase2-interface <tunnel-name>Displays the running config. Always compare this to the peer’s configuration side by side when debugging no proposal chosen errors.
Check the IPsec event log from CLI
execute log filter category 6
execute log filter field tunnelid <tunnel-name>
execute log displayCategory 6 = IPsec event logs. Shows IKE negotiation events, tunnel up/down transitions, and XAUTH results with timestamps.
XAUTH specific debug — when tunnel connects but user auth fails
diagnose debug application fnbamd -1
diagnose debug enablefnbamd is the FortiGate authentication daemon. Shows the full XAUTH credential validation flow — group lookup, user status check, and the accept/reject decision. If a user exists but keeps getting XAUTH-rejected, this output shows exactly why.
Check DPD (Dead Peer Detection) events
diagnose debug application ike -1
diagnose debug enableDPD events appear in IKE debug output as DPD messages. If DPD is dropping tunnels prematurely, you’ll see dpd: peer is not responding followed by the tunnel being cleared.
Check anti-replay and ESP errors
diagnose vpn ipsec statusShows global IPsec statistics including ESP decrypt failures, anti-replay drops, and authentication errors. Anti-replay drops (out-of-sequence ESP packets) are common on links with high jitter and indicate a need to increase the replay window or investigate the network path.
Check NP (hardware offload) IPsec stats
diagnose npu np6 ipsec-statsOn NP6/NP7 hardware, IPsec encryption can be offloaded to the network processor. This command shows hardware-accelerated encrypt/decrypt counters. If software counters increment but hardware counters don’t, offload may be disabled — check set npu-offload in the phase1 config.
Complete IPsec Debug Workflow — In Order
Use this exact sequence when a tunnel won’t come up:
# Step 1 — clean state
diagnose debug reset
diagnose debug disable
# Step 2 — enable IKE debug
diagnose debug application ike -1
diagnose debug enable
# Step 3 — on the client, initiate the connection
# Watch the output — Phase 1 proposal exchange appears first
# Step 4 — if Phase 1 succeeds but Phase 2 fails, also run:
diagnose debug application ikemgr -1
# Step 5 — if tunnel is up but XAUTH fails:
diagnose debug application fnbamd -1
# Step 6 — check SA status
diagnose vpn ike gateway list
diagnose vpn tunnel list
get vpn ipsec tunnel details
# Step 7 — if tunnel is up but traffic won't pass:
diagnose debug flow filter addr <client-ip>
diagnose debug flow show function-name enable
diagnose debug flow trace start 100
# Step 8 — always clean up
diagnose debug disable
diagnose debug resetIPsec Error Messages Decoded
| Message in debug output | Meaning | Fix |
| no proposal chosen | Phase 1 or Phase 2 cipher suite mismatch | Compare encryption, hash, and DH group on both sides — must be identical |
| invalid id information | Peer ID mismatch — aggressive mode identity rejected | Set peertype any on FortiGate or match the peer ID explicitly |
| authentication failed | Pre-shared key mismatch | Verify PSK character-for-character on both sides, check for trailing spaces |
| XAUTH user authentication failure | Wrong username or password, or user not in the XAUTH group | Check show user group <group> for membership, check user status is enabled |
| cannot respond to IPsec SA request | Phase 2 selectors don’t match | Check src-subnet and dst-subnet in Phase 2 config |
| DPD: peer is not responding | Remote peer stopped responding to keepalives | Check remote device is up, check UDP 500/4500 path, adjust DPD timers |
| the peer is not responding to delete requests | Stale SA — remote end already cleared the tunnel | Run diagnose vpn ike gateway flush to clear locally |
| received notify type INITIAL_CONTACT | Remote peer restarted and is starting fresh | Normal — FortiGate will re-negotiate automatically |
| ESP replay check failed | Out-of-sequence packets — anti-replay drop | Check network path for reordering, consider increasing replay window |
| mode-cfg request accepted | Mode Config IP assignment succeeded | Normal — client received its virtual IP |
Read Also:FortiGate DHCP over IPsec VPN
Bhardwaj Vishnu is a Network Security Engineer with hands-on expertise in enterprise firewall management, network automation, and multi-vendor infrastructure. He holds Fortinet NSE 4/NSE 5, a Cisco CCNA, and the full Cisco Meraki certification track. He architects FortiGate security policies, manages Cisco Meraki MX/MS/MR deployments, and handles enterprise routing and switching. Every guide on netconfig.io comes from direct production experience — real CLI commands, verified configs.
