Fortinet Firewall Troubleshooting Commands: The Complete Reference Guide (FortiOS 7.x)
Keywords: Fortinet Troubleshooting Commands • FortiGate CLI Commands • FortiOS Debug Commands • FortiGate Packet Sniffer • FortiGate Debug Flow • FortiGate VPN Troubleshooting • Fortinet Show Commands • FortiGate Session Table • FortiGate Firewall Policy Debug • FortiGate IPsec Troubleshooting • FortiGate SD-WAN Troubleshooting • FortiGate HA Troubleshooting • FortiOS Diagnose Commands • FortiGate SSL-VPN Debug
FortiGate troubleshooting follows a different rhythm from Cisco. The commands are more verbose, the debug framework is more powerful, and the diagnostic tools go deeper than what most engineers use. The diagnose debug flow command alone can trace a packet through every processing stage on the firewall and tell you exactly where it was dropped and why. That’s the level of specificity this guide covers.
May 2026 | ⏱ 35 min read | FortiOS 7.2.x / 7.4.x / 7.6.x • FortiGate All Models | ⚙ Network Engineers • Security Admins • NOC Teams
⚠ Before Using Debug Commands in Production
Debug commands on FortiGate generate intensive output. Always check CPU first (get system performance status). Use packet filters to limit debug scope. Disable debug immediately after capturing output with diagnose debug disable and diagnose debug reset. Leaving debug enabled on a busy FortiGate can seriously degrade performance.
Sections in This Guide
|
1. First Commands on Any FortiGate Issue 2. System Health & Performance 3. Interface & Link Troubleshooting 4. Session Table & Traffic Flow 5. Routing Troubleshooting 6. Firewall Policy Troubleshooting 7. Packet Sniffer (diagnose sniffer) |
8. Debug Flow (diagnose debug flow) 9. VPN Troubleshooting (IPsec & SSL-VPN) 10. DHCP & DNS Troubleshooting 11. SD-WAN Troubleshooting 12. HA Cluster Troubleshooting 13. FortiGuard & License Verification 14. Master Quick-Reference Table & FAQ |
1. First Commands to Run on Any FortiGate Issue
When something breaks, start here. These five commands give you a complete snapshot of the device’s state: version, health, interfaces, routes, and active sessions. Run them before touching anything.
# The FortiGate first-five troubleshooting commands
get system status # FortiOS version, serial, HA mode, license status get system performance status # CPU, memory, sessions, uptime — is device healthy? get system interface # All interfaces, IPs, states, speeds get router info routing-table all # Full routing table diagnose sys session stat # Session table statistics (count, capacity)
get system status
The single command that tells you what you’re working with: FortiOS build, model, uptime, HA state, and whether licenses are active. Always run this first when connecting to an unfamiliar device or at the start of a support case.
Version: FortiGate-100F v7.4.3,build2573,240301 (GA.F) ← Exact version + build Serial-Number: FGT100FTK23000001 ← Used for licensing/support BIOS version: 05000012 System time: Tue May 13 10:24:55 2026 Log hard disk: Available Hostname: FGT-HQ-GW Distribution: International Branch point: 2573 Release Version Information: GA FortiASIC NP6Xlite, CP9X License Status: Valid ← License OK VM Resources: 2 CPUs, 4096MB RAM HA: Active-Passive, role: primary ← HA mode and role
get system performance status
Real-time CPU, memory, and session count. If CPU is over 80% before you even start troubleshooting, the device may be under attack, running heavy debug, or undersized for the current traffic load. Memory conservation mode kicks in automatically when free memory drops too low and disables some features to prevent a crash.
CPU states: 0%us 1%sy 0%ni 98%id 0%wa 0%hi 1%si 0%st CPU0 states: 0%us 1%sy 0%ni 98%id 0%wa 0%hi 1%si 0%st Memory: 4096072k total, 2814280k used (68%), 1281792k free ← 68% used = OK Memory: 3900000k total, 3900000k used (99%), 0k free ← CRITICAL — conservation mode Average network usage: 820 kbps in 1 minute, 1200 kbps in 10 minutes Average sessions: 14832 sessions in 1 minute ← Active sessions Average session setup rate: 42 sessions/second in last 1 minute Current sessions: 14921 ← Current live sessions Hard disk: Not installed Uptime: 14 days, 3 hours, 22 minutes
2. System Health & Performance Commands
diagnose sys top | diagnose sys top-summary
Real-time view of process resource consumption — similar to Linux top. diagnose sys top runs live and refreshes continuously (press q to quit). diagnose sys top-summary gives a one-time snapshot sorted by CPU or memory. Run this when the FortiGate is sluggish — find which daemon is consuming the most resources. Common high-CPU culprits: ipsengine (IPS processing), sslvpnd (SSL-VPN), httpsd (GUI/API activity), scanunitd (AV scanning).
Run Time: 14 days, 3 hours and 24 minutes 11:04PM up 14 days, 3:24, load average: 0.41, 0.38, 0.36 32 processes; 1 running, 31 sleeping, 0 stopped, 0 zombie PID USERNAME PRI NI VSZ RSS CPU MEM TIME+ COMMAND 1234 admin 20 0 428M 89M 3 2 0:15.32 ipsengine 2345 admin 20 0 892M 512M 41 12 8:22.01 scanunitd ← HIGH CPU: AV scanning 1122 admin 20 0 124M 34M 1 1 0:02.14 miglogd 3344 admin 20 0 224M 67M 0 2 0:08.45 forticldd
diagnose hardware sysinfo memory
Detailed memory breakdown. More granular than the performance status output. Shows kernel memory (MemTotal/MemFree), buffer, cached, and SwapTotal. When FortiGate enters memory conservation mode, it logs a critical syslog message and may disable proxy-based inspection and other features. The threshold varies by model.
MemTotal: 4096072 kB MemFree: 1281792 kB ← Healthy MemAvailable: 2104832 kB Buffers: 89344 kB Cached: 842876 kB SwapCached: 0 kB Active: 1482344 kB Inactive: 932512 kB
diagnose hardware sysinfo cpu | fnsysctl cat /proc/cpuinfo
Shows physical CPU details and per-core utilization. When overall CPU is high, this identifies which cores are saturated. Useful on multi-core models where NP (Network Processor) offloading should be handling forwarding — if software processes are handling traffic that should be offloaded to the NP, investigate NP offload settings.
# Check NP offload status — what's being hardware-accelerated diagnose npu np6xlite-list diagnose npu np6xlite show session-list # Verify current CPU usage per core diagnose hardware sysinfo cpu CPU: 4-core Intel Xeon 2.40GHz CPU 0: busy 2% CPU 1: busy 41% ← One core spiking — check which process owns it CPU 2: busy 3% CPU 3: busy 1%
3. Interface & Link Troubleshooting
get system interface physical | diagnose netlink interface list
Also: get system interface port1 (for a specific interface)
Shows all interfaces with their speeds, duplex, and link status at the physical layer. diagnose netlink interface list gives lower-level stats including packet/byte counters and error counts per interface. Critical for identifying duplex mismatches, CRC errors, and speed negotiation issues.
# Physical interface details get system interface physical == [port1] ==[name]: port1 ==[speed]: 1000full ← 1Gbps full duplex (good) ==[ip]: 203.0.113.1/30 ==[status]: up ← Link up ==[txpkt]: 4841293 ==[rxpkt]: 3920481 == [port2] ==[name]: port2 ==[speed]: 10half ← 10Mbps HALF duplex = duplex mismatch! ==[status]: up ==[txpkt]: 1234 ==[rxpkt]: 987 ==[CRC error]: 1847 ← CRC errors = bad cable or mismatch # Low-level interface statistics with error counters diagnose netlink interface list port1
fnsysctl ifconfig port1 | diagnose ip address list
fnsysctl ifconfig shows the underlying Linux interface stats (packets in/out, errors, dropped packets). diagnose ip address list shows all IP addresses assigned to all interfaces including dynamic addresses received via DHCP or PPPoE.
# Show all assigned IPs (including DHCP/PPPoE addresses) diagnose ip address list IP=203.0.113.1->203.0.113.2 mask=255.255.255.252 dev=port1 flags=P IP=192.168.10.1->0.0.0.0 mask=255.255.255.0 dev=internal flags=P IP=10.0.0.5->10.0.0.1 mask=255.255.255.0 dev=port3 flags=D ← D=DHCP assigned # Low-level ifconfig output fnsysctl ifconfig port1 port1 Link encap:Ethernet HWaddr 00:09:0f:aa:bb:cc inet addr:203.0.113.1 Bcast:203.0.113.3 Mask:255.255.255.252 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3920481 errors:0 dropped:142 overruns:0 frame:0 ← Drops = possible overload TX packets:4841293 errors:0 dropped:0 overruns:0 carrier:0
diagnose netlink brctl name vswitch1
For FortiGate hardware switch interfaces (the internal switch zone), this command shows which physical ports are in the software switch and their individual statistics. Use when traffic is not flowing through a specific switch port but the FortiGate thinks everything is fine.
4. Session Table & Traffic Flow Commands
The session table is the heart of FortiGate’s stateful processing. Every permitted connection has a session entry. When traffic flows unexpectedly or stops flowing, the session table tells you which policy matched, whether NAT was applied, which tunnel it uses, and what state the connection is in.
diagnose sys session list | diagnose sys session filter
Also: diagnose sys session stat | diagnose sys session6 list (IPv6)
The most powerful session troubleshooting tool. Filter sessions by source IP, destination IP, port, or policy ID before running list — without filters, a busy FortiGate could output tens of thousands of session entries and bring the console to its knees. Always filter first.
# ALWAYS set filters before listing sessions diagnose sys session filter src 192.168.10.5 # Filter by source IP diagnose sys session filter dst 8.8.8.8 # Filter by destination diagnose sys session filter dport 443 # Filter by destination port diagnose sys session filter policy-id 1 # Filter by policy ID diagnose sys session filter clear # Clear all filters # Now list matching sessions diagnose sys session list session info: proto=6 proto_state=01 duration=47 expire=3574 timeout=3600 flags=00000000 orig-src-addr=192.168.10.5:52341 orig-dst-addr=8.8.8.8:443 proto=6 reply-src-addr=8.8.8.8:443 reply-dst-addr=203.0.113.1:52341 ← NAT visible here state=may_dirty policy_dir=0 tunnel=/ vlan_cos=0/-1 policy_id=1 ← Which policy matched npu_info: flag=0x01... # Session statistics (count, capacity, hit rate) diagnose sys session stat session table: max 180000, used 14921, memory 0% ← 14921/180000 = fine session table: max 180000, used 179999, memory 99% ← Table nearly full!
diagnose sys session clear | diagnose sys session filter; diagnose sys session clear
Clears sessions from the table. Use with extreme caution in production — clearing all sessions drops all active connections. The safer approach: set a filter first, then clear only matching sessions. Useful when stale sessions are causing connection problems (the old session is in a half-open state and blocking new connections to the same destination).
# Clear ONLY sessions from a specific source (safer) diagnose sys session filter src 192.168.10.5 diagnose sys session clear # Clear sessions for a specific destination (e.g., after fixing routing) diagnose sys session filter dst 10.2.0.0/24 diagnose sys session clear # ⚠ Clear ALL sessions — only do this if you know the impact diagnose sys session clear # without filters = drops everything!
5. Routing Troubleshooting Commands
get router info routing-table all | get router info routing-table details <prefix>
Also: get router info routing-table static | get router info routing-table ospf | get router info routing-table bgp
Shows the active routing table. The letter codes: S=static, C=connected, O=OSPF, B=BGP, D=EIGRP. The notation [distance/metric] shows administrative distance and metric. If the default route is missing (no 0.0.0.0/0 entry), the FortiGate won’t forward traffic to the internet regardless of firewall policy.
Routing table for VRF=0 S* 0.0.0.0/0 [10/0] via 203.0.113.9, port1 ← Default route present (good) Gateway of last resort is not set ← NO default route (problem!) S 10.10.0.0/24 [10/0] via 10.0.0.1, port2 ← Static route C 192.168.10.0/24 is directly connected, internal ← Connected O 172.16.0.0/16 [110/2] via 10.0.0.2, port3 ← OSPF route B 203.0.113.0/24 [20/0] via 10.0.1.1, wan1 ← BGP route # Check what path a specific IP would take get router info routing-table details 8.8.8.8 Routing entry for 0.0.0.0/0 Known via "static", distance 10, metric 0 Routing Descriptor Blocks: * 203.0.113.9, via port1 ← Next hop and exit interface
get router info ospf neighbor | get router info ospf interface
FortiGate OSPF neighbor and interface status. Neighbor state should be FULL for proper adjacency. If stuck in EXSTART, it almost always indicates an MTU mismatch between the FortiGate and its neighbor. Fix with ip mtu-ignore in the OSPF interface config, or correct the MTU.
get router info ospf neighbor OSPF process 1, VRF 0: Neighbor ID Pri State Dead Time Address Interface 10.0.0.2 1 Full/DR 00:00:36 10.0.0.2 port3 10.0.0.3 0 ExStart/DROther 00:00:38 10.0.0.3 port3 ← MTU mismatch # OSPF interface details — check hello/dead timers get router info ospf interface port3 port3 is up, line protocol is up Internet Address 10.0.0.1/30, Area 0.0.0.0 Process ID 1, Router ID 192.168.0.1, Network Type BROADCAST Cost: 10, Transmit Delay is 1 sec, State DR, Priority 1 Timer intervals configured, Hello 10s, Dead 40s ← Must match peer DR: 10.0.0.1 BDR: 10.0.0.2 Nbr Count: 2
get router info bgp summary | get router info bgp neighbors <IP>
BGP neighbor status. The State/PfxRcd column shows the session state and number of prefixes received. Established with a non-zero prefix count is healthy. Active means the FortiGate is trying to connect but the peer isn’t responding — check TCP 179 reachability, AS numbers, and authentication keys.
get router info bgp summary BGP router identifier 203.0.113.1, local AS number 65001 BGP table version is 12, main routing table version 12 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 203.0.113.9 4 65000 4821 4812 12 0 0 2w1d 14 ← 14 prefixes, healthy 10.0.1.1 4 65002 0 0 0 0 0 00:02:14 Active ← Not connected!
6. Firewall Policy Troubleshooting
diagnose firewall iprope lookup <src> <dst> <port> <proto> <src-intf>
The policy lookup tool: tells you exactly which policy would match a specific traffic flow without generating any actual traffic. Equivalent to the Policy Lookup in the GUI but faster from the CLI. The protocol number for TCP is 6, UDP is 17, ICMP is 1.
# Which policy matches: 192.168.10.5 → 8.8.8.8:443 TCP from internal interface diagnose firewall iprope lookup 192.168.10.5 8.8.8.8 443 6 internal Result: policy_id=1 state=accept ← Policy 1 matches, action = accept # If denied: Result: policy_id=0 state=deny ← Policy 0 = implicit deny (no policy matched) Result: policy_id=5 state=deny ← Explicit deny rule #5 # Check hit counters per policy (GUI: Policy & Objects → Firewall Policy) diagnose firewall policy 0 list # Lists policies with hit counts
diagnose firewall packet-count | diagnose test application ipsmonitor 1
Check packet processing counters and IPS engine status. When traffic is being blocked unexpectedly, IPS signatures can be the cause — especially if the security profile is in blocking mode and a signature has a false positive. diagnose test application ipsmonitor 1 shows IPS engine health.
# Check IPS engine status diagnose test application ipsmonitor 1 IPS engine 1 status: running, id=1, fd=-1, ports: 3, events: 0 IPS signatures: 34921 ← Signature count IPS engine memory: 1024K max, 892K used IPS engine loaded: yes # If IPS is blocking legitimate traffic, check the log: # Log & Report → Security Events → Intrusion Prevention # Note the signature ID and create an IPS exemption in the profile
diagnose firewall auth list | diagnose firewall fqdn list
auth list shows currently authenticated users and which policy group they belong to — critical when identity-based policies aren’t matching. fqdn list shows the resolved IP addresses for FQDN-based address objects. If an FQDN policy isn’t matching, the FQDN may have resolved to an IP that doesn’t match the traffic.
# List authenticated users (for identity-based policies) diagnose firewall auth list Username: john.doe IP: 192.168.10.5 Method: FSSO Policy-group: Corp-Users Username: jane.smith IP: 192.168.10.8 Method: Local Policy-group: Admins # Check FQDN resolution (for FQDN-based firewall objects) diagnose firewall fqdn list www.example.com: 93.184.216.34, 2606:2800:220:1:248:1893:25c8:1946 # If FQDN shows wrong IPs, clear and refresh: diagnose firewall fqdn flush
7. Packet Sniffer — diagnose sniffer packet
FortiGate’s built-in packet sniffer is equivalent to running tcpdump directly on the firewall’s interfaces. It captures traffic at the interface level, before or after firewall processing depending on the interface direction. Use it to confirm whether traffic is arriving on the expected interface and whether the firewall is sending replies.
Sniffer Command Syntax
diagnose sniffer packet <interface> <filter> <verbose> <count> <timestamp>
interface: any, port1, internal, ssl.root, etc.
filter: tcpdump-style BPF filter (or none for all traffic)
verbose: 1=headers only, 2=IP headers, 3=IP+data, 4=Ethernet+IP, 5=Ethernet+IP+data, 6=ASCII text
count: number of packets to capture (0 = infinite, Ctrl+C to stop)
timestamp: a=absolute time, l=relative time (optional)
# Essential sniffer examples
# Capture all traffic on WAN port (verbose 4 = Ethernet + IP headers) diagnose sniffer packet port1 none 4 50 a # Output: 10:24:55 192.168.10.5:52341 -> 8.8.8.8:443 syn # Capture ICMP only (troubleshoot ping) diagnose sniffer packet any 'icmp' 4 20 a # Capture traffic to/from a specific host on any interface diagnose sniffer packet any 'host 192.168.10.5' 4 0 a # Capture HTTPS traffic on WAN (see what's going out) diagnose sniffer packet port1 'tcp port 443' 4 100 a # Capture traffic between two hosts (and clause) diagnose sniffer packet any 'host 192.168.10.5 and host 8.8.8.8' 4 50 a # Capture DNS queries (UDP 53) diagnose sniffer packet any 'udp port 53' 4 30 a # Capture BGP sessions (TCP 179) diagnose sniffer packet any 'tcp port 179' 4 20 a # Full packet with ASCII data (for protocol inspection) diagnose sniffer packet any 'host 192.168.10.5' 6 10 a
Sniffer Output Interpretation
interfaces=[port1] filters=[host 192.168.10.5] 14.247037 internal -- 192.168.10.5.52341 -> 8.8.8.8.443 ← Arrived on internal (from LAN) 14.247039 port1 -- 203.0.113.1.52341 -> 8.8.8.8.443 ← Left on port1 (NAT'd to WAN IP) 14.259103 port1 -- 8.8.8.8.443 -> 203.0.113.1.52341 ← Reply arrived on WAN 14.259105 internal -- 8.8.8.8.443 -> 192.168.10.5.52341 ← Reply forwarded to LAN client # Healthy pattern: traffic arrives on source interface, exits on dest interface, # reply arrives on dest interface, forwarded back to source interface # Problem: Traffic arrives on internal but never exits port1 # → Policy blocked it or NAT missing # → Use debug flow to find out exactly where it was dropped
Saving sniffer output to PCAP: Append l as the 6th parameter to save in PCAP format. Upload to a TFTP server and open in Wireshark: diagnose sniffer packet any 'host 10.0.0.1' 6 0 a l — the output can be redirected using the FortiGate’s built-in TFTP client or copied from the session buffer on some models.
8. Debug Flow — The Most Powerful Troubleshooting Tool
diagnose debug flow traces a specific packet through every single processing stage inside the FortiGate — routing lookup, policy match, NAT, UTM inspection, VPN processing — and prints a line of output at each stage. When a packet is dropped, the debug flow output tells you exactly which stage dropped it and why. There is no more powerful troubleshooting tool on a FortiGate.
⚠ CPU Warning
Debug flow captures every packet matching your filter in real time. Always use the most specific filter possible. Never run debug flow without a source IP filter on a production firewall. On busy systems, even a single-host filter can generate thousands of lines per second. Set a packet count limit (5–20 is usually enough) and disable debug immediately after.
Complete Debug Flow Procedure
# STEP 1: Reset any previous debug settings diagnose debug reset diagnose debug disable # STEP 2: Set packet filter (ALWAYS do this) diagnose debug flow filter addr 192.168.10.5 # By source or destination IP diagnose debug flow filter daddr 8.8.8.8 # Destination IP diagnose debug flow filter port 443 # By port diagnose debug flow filter proto 6 # Protocol (6=TCP, 17=UDP, 1=ICMP) # Check your filter is correct diagnose debug flow filter # STEP 3: Enable function name output (more descriptive) diagnose debug flow show function-name enable diagnose debug flow show iprope enable # STEP 4: Set trace limit (10 packets is usually enough) diagnose debug flow trace start 10 # STEP 5: Enable debug output diagnose debug enable # STEP 6: Trigger the traffic (ping or test connection from the client) # STEP 7: Read the output (see below) # STEP 8: DISABLE DEBUG — DO NOT FORGET THIS diagnose debug disable diagnose debug flow trace stop diagnose debug reset
Debug Flow Output — Reading the Results
# PERMITTED TRAFFIC — healthy flow
id=20085 trace_id=1 func=print_pkt_detail line=5845 msg="vd-root:0 received a packet(proto=6, 192.168.10.5:52341->8.8.8.8:443) tun_id=0.0.0.0 tun_id6=:: from internal." id=20085 trace_id=1 func=resolve_ip_tuple_fast line=5901 msg="Find an existing session, id-00120012, original direction" id=20085 trace_id=1 func=iprope_fwd_check line=2349 msg="gnum-100006, check-00000000, result-accept, to port1" ← Policy accepted id=20085 trace_id=1 func=ipd_post_route_handler line=259 msg="out port1, state=may_dirty, outif=5" id=20085 trace_id=1 func=nf_nat_ipv4_fn line=438 msg="before NAT: id=00120012, 192.168.10.5:52341->8.8.8.8:443" id=20085 trace_id=1 func=nf_nat_ipv4_fn line=455 msg="after NAT: id=00120012, 203.0.113.1:52341->8.8.8.8:443" ← NAT applied
# DENIED TRAFFIC — what a drop looks like
id=20085 trace_id=2 func=print_pkt_detail line=5845 msg="vd-root:0 received a packet(proto=6, 192.168.10.5:3389->10.20.0.1:3389) from internal." id=20085 trace_id=2 func=resolve_ip_tuple_fast line=5901 msg="allocate a new session-000c001a" id=20085 trace_id=2 func=iprope_fwd_check line=2349 msg="gnum-100006, check-00000000, result-deny, to port2" ← Policy DENIED id=20085 trace_id=2 func=__iprope_tree_check line=791 msg="gnum-100004, ret-default deny" ← Implicit deny (no policy matched) id=20085 trace_id=2 func=ip_session_delete line=2476 msg="delete a session"
| Debug Flow Message | Meaning & Action |
| result-deny, ret-default deny | No policy matched — implicit deny. Check source/destination/service in policy |
| result-deny, policy_id=<N> | Explicit deny policy N matched. Review that policy rule |
| no matching route | No route in the routing table for the destination. Add a route |
| ip_conn_limit | Per-IP connection limit hit. Adjust in firewall policy or security profile |
| anti_replay | IPsec replay check failed. Check clock sync between VPN peers |
9. VPN Troubleshooting — IPsec & SSL-VPN
IPsec VPN Troubleshooting
diagnose vpn ike gateway list | diagnose vpn tunnel list
The first two commands for any IPsec problem. IKE gateway list shows Phase 1 status — whether IKE has authenticated with the remote peer. Tunnel list shows Phase 2 (IPsec SA) status with bytes in and out. Bytes moving in both directions means traffic is flowing through the tunnel. Zero bytes inbound usually indicates routing or policy issues on the remote side.
# Phase 1 — IKE SA status diagnose vpn ike gateway list vd: root/0 name: Site-to-HQ version: IKEv2 interface: port1 10 addr: 203.0.113.1:500 -> 198.51.100.1:500 created: 12s ago IKE SA: created 1/1 established 1/1 time 200/200/200 ms phase2: created 1/1 established 1/1 dpd: mode=on-demand on=1 idle=20000ms retry=3 count=0 ← DPD working # Phase 2 — IPsec SA with traffic counters diagnose vpn tunnel list name Site-to-HQ name=Site-to-HQ ver=2 serial=1 203.0.113.1:0->198.51.100.1:0 lgwy=static/1 tun=tunnel/act mode=auto/1 encap=AUTODEL/672 options[0228]=frag-rfc/npu proxyid=Site-to-HQ proto=0 sa=1 ref=4 serial=0 src: 0:192.168.10.0/255.255.255.0:0 dst: 0:10.20.0.0/255.255.255.0:0 SA: ref=6 options=00000618 type=00 soft=0 mtu=1438 expire=28456/0 life: type=01 bytes=4096000000/4096000000 idles=1800/1800 dec: spi=ae421234 esp=aes key=16 ae421234... enc: spi=20813412 esp=aes key=16 20813412... stat: rxp=4821 txp=5034 rxb=5241782 txb=6891234 ← Packets/bytes flowing both ways # If rxp=0 txp=0: No traffic in SA — check routing to remote subnet # If txp>0 rxp=0: Traffic going out, nothing coming back — remote end issue
diagnose debug application ike -1 | diagnose debug application iked -1
Real-time IKE debug output. The -1 sets maximum verbosity. Shows IKE Phase 1 and Phase 2 negotiation messages, authentication attempts, and proposal mismatches. Critical for troubleshooting tunnels that don’t establish.
# Enable IKE debug (set filter first if possible) diagnose debug application ike -1 diagnose debug enable # Common error messages and their meanings: NO_PROPOSAL_CHOSEN # Phase 1 or Phase 2 proposals don't match # Check: encryption, hash, DH group, lifetime on both sides AUTHENTICATION_FAILED # Pre-shared key mismatch or certificate issue # Verify PSK is identical on both sides (case-sensitive) TS_UNACCEPTABLE # Traffic selectors (Phase 2 subnets) don't match # Check local/remote subnet definitions in Phase 2 INVALID_ID_INFORMATION # Peer identifier mismatch # Check IKE ID type (IP, FQDN, email) on both ends # ALWAYS disable after troubleshooting: diagnose debug disable diagnose debug reset
IPsec VPN Troubleshooting Checklist
| Problem | Command & Fix |
| Phase 1 won’t establish | diagnose debug application ike -1 → look for NO_PROPOSAL_CHOSEN or AUTH_FAILED |
| Phase 1 up, Phase 2 fails | Check Phase 2 proposals and traffic selectors (local/remote subnet match) |
| Tunnel up, no traffic | Check static route pointing remote subnet through tunnel; check firewall policy permits traffic via tunnel interface |
| Tunnel drops frequently | Check DPD settings; verify NAT-T if behind NAT; check lifetime mismatch |
SSL-VPN Troubleshooting
diagnose vpn ssl list | diagnose vpn ssl statistics
Shows active SSL-VPN sessions and statistics. Note: Fortinet announced SSL-VPN deprecation in FortiOS 7.4+. New deployments should use IPsec with FortiClient or ZTNA instead. These commands remain relevant for existing SSL-VPN deployments.
# Active SSL-VPN sessions diagnose vpn ssl list SSL VPN connection id: 2001 Index: 0 User: john.doe Group: SSL-VPN-Users Client IP: 203.0.100.5 Virtual IP: 10.212.134.1 ← IP assigned to client's tunnel Tunnel up time: 1:24:32 Bytes recv: 1247891 bytes sent: 4819237 # SSL-VPN statistics diagnose vpn ssl statistics SSL-VPN Session(s): 12/100 ← 12 of 100 licensed sessions in use SSL-VPN Session(s) (Tunnel): 10 SSL-VPN Session(s) (Web): 2 # Debug SSL-VPN connections diagnose debug application sslvpn -1 diagnose debug enable # Look for: authentication failures, certificate errors, tunnel setup issues diagnose debug disable
10. DHCP & DNS Troubleshooting
diagnose sys dhcp server list | get system dhcp server
Shows active DHCP leases and server configuration. When clients are not getting IPs, this confirms whether the FortiGate’s DHCP server is running, which pool it’s using, and whether the pool is exhausted.
# Show active DHCP leases diagnose sys dhcp server list DHCP server (1): vdom: root interface: internal start-ip: 192.168.10.100 end-ip: 192.168.10.200 lease-time: 86400 leases: 192.168.10.100 00:50:56:aa:11:22 pc-accounting expire=86351 ← Lease active 192.168.10.101 00:50:56:aa:33:44 laptop-john expire=82341 # Count entries — if same as end-ip minus start-ip = pool full # Debug DHCP server in real time diagnose debug application dhcpd -1 diagnose debug enable # Generate a DHCP Discover from a client and watch the output # Look for: DISCOVER received, OFFER sent, REQUEST received, ACK sent diagnose debug disable # Test DNS resolution from the FortiGate itself diagnose nslookup google.com diagnose nslookup google.com 8.8.8.8 # Query specific DNS server
diagnose test application dnsproxy 7 | diagnose dns query
FortiGate includes a DNS proxy that intercepts client DNS queries for filtering and inspection. diagnose test application dnsproxy 7 shows DNS proxy statistics. If clients get NXDOMAIN for valid domains, DNS filtering may be blocking them, or the FortiGate’s DNS proxy may not be resolving correctly.
# DNS proxy statistics diagnose test application dnsproxy 7 DNS proxy statistics: queries: 14821 cached: 11234 forwarded: 3587 blocked: 842 ← 842 DNS queries blocked by DNS filter nxdomain: 12 servfail: 3 # Check if DNS filter is blocking a domain # GUI: Security Profiles → DNS Filter → check the blocked list in logs # Log & Report → Security Events → DNS Filter # Test DNS resolution from FortiGate execute nslookup google.com execute nslookup blocked-domain.com # Will show blocked if DNS filter active
11. SD-WAN Troubleshooting Commands
diagnose sys sdwan member | diagnose sys sdwan health-check
Also: diagnose sys sdwan intf-sla-log | diagnose sys sdwan service
The essential SD-WAN diagnostic commands. member shows each WAN interface’s state in the SD-WAN zone. health-check shows which performance SLAs each member is passing or failing. If a member fails its SLA, traffic should automatically failover to another member — verify this is happening with the service command.
# SD-WAN member status diagnose sys sdwan member Members: 1(port1): flags=0 weight=1 priority=0 zone=1 status=active gateway: 203.0.113.9 preference=0 sla-quality: priority=0, seq=1 2(port2): flags=0 weight=1 priority=0 zone=1 status=inactive ← WAN2 down! gateway: 198.51.100.1 preference=0 # Health check status per member diagnose sys sdwan health-check Health Check: HC-Internet interface: port1 latency=12.3ms jitter=0.8ms packetloss=0% sla_pass=yes interface: port2 latency=999ms jitter=0ms packetloss=100% sla_pass=no ← WAN2 SLA failing Health Check: HC-VoIP interface: port1 latency=48ms jitter=28ms packetloss=0% sla_pass=no ← Jitter exceeding SLA threshold interface: port2 latency=8ms jitter=1ms packetloss=0% sla_pass=yes # Which SD-WAN rule is directing which traffic diagnose sys sdwan service 0 Service(1): Address Mode(IPV4) flags=0 TOS(0x0/0x0), protocol(0: 1->65535), mode(sla), link cost factor(latency) Member sub interface: port1: SLA-met priority=0 weight=1 port2: SLA-notmet priority=0 weight=1
diagnose sys sdwan intf-sla-log <interface> <health-check-name>
Shows historical SLA measurement log for a specific interface and health check. Useful for identifying when an SLA failure started — was it a recent event or has this link been degraded for hours? The log shows per-probe latency, jitter, and loss measurements with timestamps.
diagnose sys sdwan intf-sla-log port1 HC-Internet Timestamp Latency Jitter Loss 2026-05-13 10:00:00 11.2ms 0.4ms 0% ← Normal 2026-05-13 10:05:00 12.1ms 0.8ms 0% 2026-05-13 10:10:00 89.4ms 42.1ms 15% ← Link degraded at 10:10 2026-05-13 10:15:00 999ms 0ms 100% ← Link completely failed 2026-05-13 10:20:00 999ms 0ms 100%
12. HA Cluster Troubleshooting
get system ha status | diagnose sys ha dump-by-vcluster
The primary HA health commands. get system ha status shows the overall cluster state, which unit is primary, uptime, and synchronized configuration status. diagnose sys ha dump-by-vcluster gives per-VDOM detailed HA information.
get system ha status HA Health Status: OK Model: FortiGate-100F Mode: Active-Passive Group: 1 Debug: 0 Heartbeat interval: 200 Heartbeat lost threshold: 10 HA Direct: on/enabled FW Status: Primary HA Uptime: 2w1d4h Slave: ← Peer unit info FGT100FTK23000002 is in Slave role is 1 HA heartbeat lost packets heartbeat interfaces: ha1(up) ha2(up) Configuration Status: FGT100FTK23000001(updated 10s ago) in-sync: yes ← Config sync OK FGT100FTK23000002(updated 10s ago) in-sync: no ← Config OUT OF SYNC! # Verify heartbeat interface status diagnose sys ha dump-by-vcluster Cluster member index 0 (master): serial: FGT100FTK23000001 HA state: primary HBDEV: ha1(up) ha2(up) ← Both HA heartbeat links up Monitor interfaces: port1 port2 internal Monitored interfaces status: port1=up port2=up internal=up
execute ha manage <index> <admin> | diagnose sys ha checksum
execute ha manage connects to the secondary unit’s CLI from the primary — you don’t need a separate console cable. diagnose sys ha checksum compares the configuration checksum between cluster members to identify sync issues.
# Connect to secondary unit CLI from primary execute ha manage 1 admin # index 1 = secondary unit # You're now on the secondary unit get system status # Verify you're on the secondary exit # Return to primary # Check config sync status between cluster members diagnose sys ha checksum show All VDOMs: global: checksum = different ← Config not in sync! vd 0 root: checksum = same ← VDOM root is in sync # Force config resync execute ha sync start
13. FortiGuard & License Verification
diagnose autoupdate versions | get system fortiguard-service
Shows the current version and last update timestamp for every FortiGuard service (IPS signatures, AV definitions, web filter categories, application signatures). If the “contract status” shows expired, signatures will stop updating even though existing signatures continue to function until the next restart. Plan renewals before expiry — the grace period varies.
diagnose autoupdate versions AV Engine --------- Version: 6.4.237 Contract Expiry Date: Mon Mar 31 2027 ← License valid Last Updated using scheduled updates on Tue May 13 09:00:00 2026 IPS Attack Engine ----------------- Version: 7.00551 Contract Expiry Date: Mon Mar 31 2027 Last Updated using scheduled updates on Tue May 13 09:00:00 2026 Web Filter ---------- Version: 7.01489 Contract Expiry Date: Mon Dec 31 2025 ← EXPIRED — web filter categories won't update Last Updated using scheduled updates on Wed Jan 1 00:00:00 2026 # Force immediate update check execute update-now # Test FortiGuard connectivity diagnose debug application update -1 diagnose debug enable execute update-now diagnose debug disable
execute ping service.fortiguard.net | diagnose test update info
When FortiGuard updates are failing, first verify the FortiGate can reach Fortinet’s update servers. FortiGuard uses UDP port 8888 and TCP 443. If your WAN has strict egress filtering, these ports may be blocked. Configure a FortiGuard override server if needed, or whitelist Fortinet’s update server subnets.
# Test connectivity to FortiGuard execute ping service.fortiguard.net execute ping update.fortiguard.net # Check FortiGuard connection status diagnose test update info FortiGuard Labs DDNS Connection: connected Server addr: 65.54.254.204:443 License status: registered # If connection shows "failed" — check: # 1. Default route exists (get router info routing-table) # 2. Firewall policy allows WAN outbound on UDP/8888 and TCP/443 # 3. DNS resolves fortiguard.net (execute nslookup service.fortiguard.net) # 4. Source interface for updates (System → FortiGuard → Source Interface)
14. Master Quick-Reference Table
| Problem / Goal | Command | Key Output |
| System & Health | ||
| Device version & license | get system status | Version, serial, HA mode, license |
| CPU & memory | get system performance status | CPU%, memory%, sessions |
| Which process using CPU | diagnose sys top | Process CPU/memory rankings |
| Interfaces & Links | ||
| All IPs and interface states | get system interface | IP, state, speed, role |
| Error counters & drops | diagnose netlink interface list port1 | RX/TX packets, errors, drops |
| Sessions & Policy | ||
| Active sessions for a host | diagnose sys session filter src X; diagnose sys session list | Policy ID, NAT, state |
| Which policy matches traffic | diagnose firewall iprope lookup <src> <dst> <port> <proto> <intf> | policy_id, accept/deny |
| Routing | ||
| Routing table | get router info routing-table all | Default route present? |
| OSPF neighbors | get router info ospf neighbor | State = FULL? |
| Packet Capture & Debug | ||
| Is traffic arriving on interface? | diagnose sniffer packet port1 'host X' 4 20 | Packets visible on interface |
| Why is traffic being dropped? | diagnose debug flow (filter → trace start → enable) | Drop reason in output |
| VPN | ||
| IPsec Phase 1 status | diagnose vpn ike gateway list | established 1/1 = healthy |
| IPsec traffic flowing? | diagnose vpn tunnel list name <tunnel> | rxp/txp counters incrementing |
⚠ Debug Cleanup Commands — Run These When Done
diagnose debug disable # Stop all debug output diagnose debug reset # Clear all debug application filters diagnose debug flow trace stop # Stop flow trace diagnose debug flow filter clear # Clear flow filter diagnose debug info # Verify: should show "debug output: disabled"
Frequently Asked Questions
Traffic is being blocked but I see no deny log entries. Why?
The implicit deny at the bottom of FortiGate’s policy list does not log by default. Enable logging on the implicit deny by going to Policy & Objects → Firewall Policy → select the implicit deny (usually the last policy) → enable Log Allowed Traffic or Log Violation Traffic. Alternatively, run debug flow to see the drop reason directly in the CLI output without relying on logging.
The sniffer shows traffic arriving on the right interface but nothing exits. What’s happening?
This is the classic indication of a firewall policy drop. Run debug flow filtered to the source IP. The output will show exactly which processing stage dropped the packet. Common causes: no matching policy (implicit deny), NAT not configured, or a security profile (IPS, AV) blocking the session. The debug flow message result-deny with a policy ID tells you which policy blocked it.
How do I check if NP (Network Processor) offloading is working?
Run diagnose npu np6xlite list (or the appropriate NP command for your model — np6, np7, etc.). The output shows how many sessions are offloaded to hardware vs processed in software. If very few sessions are offloaded when you expect hardware acceleration, check whether the traffic type supports NP offloading (some features like proxy-based inspection, IPS in certain modes, and SSL inspection disable NP offloading). The FortiGate datasheet specifies which features support ASIC acceleration.
How do I access the secondary HA unit’s CLI without a separate console cable?
From the primary unit’s CLI: execute ha manage 1 admin. This opens a management session to the secondary unit (index 1) using the admin account. You can then run any command on the secondary as if you were connected directly to its console. Type exit to return to the primary.
What is the fastest way to check if NAT is working on a FortiGate?
Two quick checks: First, ping from the FortiGate itself (execute ping 8.8.8.8) — if this succeeds, WAN connectivity and routing are fine. Then set a session filter and run diagnose sys session filter src 192.168.10.x; diagnose sys session list after traffic from the client. In the session output, look at the reply-dst-addr field — if it shows the WAN IP (not the client’s private IP), NAT is being applied correctly. If it still shows the private IP, NAT is not configured on that policy.
