Diagnostics, Monitoring, and Troubleshooting
Seeing what the FortiGate sees
Troubleshooting follows the packet: did it arrive, was it routed, did a policy accept it, and what did the profiles do with it?
Arrival is verified with interface counters, ARP (diagnose ip arp list, get system arp) and the packet sniffer: diagnose sniffer packet any 'host 10.0.0.10 and port 443' 4 a. Verbosity level 4 shows interface names and IP headers; level 6 adds Ethernet headers. Captures can be written to a file for analysis.
Routing is checked with the GUI routing monitor or get router info routing-table all, and with execute ping / execute traceroute sourced appropriately.
Policy and inspection are traced with the debug flow. Filters must be set before starting the trace - set address/port/protocol filters, then diagnose debug flow trace start 100, reproduce the traffic, and read lines such as iprope_in_check() check failed, drop, which indicates no policy matched. Always finish with diagnose debug disable and diagnose debug reset; leaving debug running degrades performance and floods the console. The session table (diagnose sys session list, with diagnose sys session filter) confirms whether a session was created and shows NAT translations, timeouts and the policy ID.
Logs and FortiView show what happened after the fact; remember that the implicit deny is not logged unless you add an explicit deny policy with logging.
Rule of thumb: no session at all points to routing or a deny policy; a session with no reply points to the server side, NAT or the return path.