FortiGate debug flow: Trace Packets Step by Step

When traffic dies on a FortiGate, the packet either never arrives, arrives but misses a policy, gets NATed incorrectly, or is silently offloaded past the CPU. diagnose debug flow answers all four questions in one trace, provided you set it up correctly: clear old filters, scope the filter tightly, turn on function names and timestamps, and cap the trace count. This guide gives the exact command sequence, what the important function names mean, and how to cross-check the result with the session table.

Prepare the CLI

diagnose debug reset
diagnose debug disable
diagnose debug console timestamp enable

Never skip the reset. Leftover filters from an earlier session produce a trace that looks plausible but belongs to someone else's traffic.

Scope the filter and start the trace

diagnose debug flow filter addr 10.10.20.15
diagnose debug flow filter port 443
diagnose debug flow filter proto 6
diagnose debug flow show function-name enable
diagnose debug flow show iprope enable
diagnose debug enable
diagnose debug flow trace start 100

filter addr matches source or destination, and can be combined with saddr/daddr, sport/dport and proto. Use diagnose debug flow filter clear between attempts, and diagnose debug flow trace stop plus diagnose debug disable when finished – an unrestricted trace on a busy firewall generates tens of thousands of lines per second.

Reading the output

id=20085 trace_id=11 func=print_pkt_detail line=5873 msg="vd-root received a packet(proto=6,
  10.10.20.15:51234->203.0.113.10:443) from port2. flag [S], seq 3312947003"
id=20085 trace_id=11 func=init_ip_session_common line=6041 msg="allocate a new session-00000e90"
id=20085 trace_id=11 func=vf_ip4_route_input line=1615 msg="find a route: gw-192.0.2.1 via port1"
id=20085 trace_id=11 func=fw_forward_handler line=989 msg="Allowed by Policy-14: SNAT"
id=20085 trace_id=11 func=__ip_session_run_tuple line=1516 msg="SNAT 10.10.20.15->192.0.2.100:51234"

The five lines above are a healthy flow: ingress on port2, new session allocated, route lookup to the next hop, policy match with the rule ID, then source NAT applied. The function names tell you which processing stage each line belongs to:

• print_pkt_detail – first line for almost every packet; confirms VDOM, ingress interface, protocol and ports.
• vf_ip4_route_input – route lookup result; a "no route" or a lookup for a different interface than expected is your routing answer.
• iprope_in_check / fw_forward_handler – policy check and final allow/deny decision, including the policy ID.
• __ip_session_run_tuple – NAT actions (SNAT/DNAT), and reverse NAT on reply packets.
• resolve_ip_tuple_fast – session matching for subsequent packets; if you never see this for later packets, the flow has no established session.

A deny shows the policy check with the reason (no matching policy, RPF check failed, web filter category, and so on). Denies tied to category matching come from the inspection layer rather than the iprope policy table.

Cross-check with the session table

diagnose sys session filter clear
diagnose sys session filter src 10.10.20.15
diagnose sys session list

If the flow appears in the session table with incrementing byte counters, traffic is passing. If it appears but counters are frozen, suspect a downstream device or asymmetric routing. If it never appears, the debug flow trace itself will show where it was dropped.

Offload caveat

diagnose npu np4 fastpath disable
diagnose npu np6 fastpath disable

NP4/NP6-accelerated interfaces move sessions into hardware and bypass the CPU path, so the debug trace can look empty while traffic flows fine. Disable fastpath on the relevant interface pair while debugging, and re-enable it afterwards.

Checklist before you start debugging

• Confirm the VDOM: the trace only covers the VDOM where the packet is processed (diagnose debug flow filter vd).
• Verify the interface pair policy exists in both directions – sessions need a matching policy for the reply path.
• Keep the trace window short, capture to a log, and stop the debug when done.

Related: FortiGate active-passive HA setup, FortiGate SSL VPN web mode, and the packet-analysis companion Wireshark TCP analysis.

原文链接：https://docs.fortinet.com/document/fortigate/7.2.3/administration-guide/054688/debugging-the-packet-flow