FortiGate · FortiOS 7.4

FortiGate debug flow commands: filter, capture and stop

Quick answer #

Debug flow explains how FortiGate processes matching traffic: it can show session lookup, route selection and policy decisions. Use it after establishing the actual client, destination, protocol and VDOM. A packet sniffer answers where traffic is visible; debug flow helps explain the processing decision.

Scope: FortiGate/FortiOS 7.4-family IPv4 flow diagnostics. Runtime debugging; bounded trace, no configuration change.

Prepare one test #

Arrange a single new client connection and note the time. Coordinate with anyone already debugging the firewall because reset and disable operations can disturb another administrator's diagnostic session. Use the VDOM that owns the client path. The example below traces traffic between two addresses in either direction, limited to TCP port 443.

Stop and clean up #

Run this immediately after the test, even if output has already stopped at the count limit:

Stop and clean up
FortiOS 7.4 · Traffic VDOM; administrative scope as described below

Diagnostic state
diagnose debug disable
Diagnostic state
diagnose debug flow trace stop
Diagnostic state
diagnose debug flow filter clear
Diagnostic state
diagnose debug reset

Start the bounded trace #

Start the bounded trace
FortiOS 7.4 · Traffic VDOM; administrative scope as described below

Diagnostic state
diagnose debug disable
Diagnostic state
diagnose debug reset
Diagnostic state
diagnose debug flow filter clear
Diagnostic state

Replace these example values: 10.20.30.40, 192.0.2.80.

diagnose debug flow filter addr 10.20.30.40 192.0.2.80 and
Diagnostic state
diagnose debug flow filter proto 6
Diagnostic state
diagnose debug flow filter port 443
Read-only
diagnose debug flow filter
Diagnostic state
diagnose debug console timestamp enable
Diagnostic state
diagnose debug flow show function-name enable
Diagnostic state
diagnose debug flow trace start 100

Stop promptly with the cleanup block on this page; shared debug state affects other administrators.

Diagnostic state
diagnose debug enable

Stop promptly with the cleanup block on this page; shared debug state affects other administrators.

Inspect the displayed filter before reproducing the problem. The and joins the two endpoint addresses; omitting it can create an address range instead of the intended pair. Protocol 6 means TCP. The port filter is bidirectional, unlike a destination-only port filter.

Interpret one trace at a time #

Follow the same trace identifier through successive lines. Record the incoming interface, session result, selected route and policy result together. An allowed-policy message establishes a policy decision at that stage; it does not demonstrate that the remote application replied. A reverse-path failure calls for checking the route back to the source in the same VDOM. An existing-session message means this is not a clean first-packet policy lookup.

When output seems incomplete #

Do not broaden the capture immediately. Recheck the endpoint after NAT, the protocol, VDOM and whether the client opened a new connection. Hardware acceleration can reduce CPU-path visibility. Keep acceleration changes out of routine copy-and-paste diagnostics and use the dedicated offload article if evidence requires that investigation.

A useful escalation bundle contains this short trace plus a simultaneous sniffer capture and filtered session entry. Those three views distinguish a policy decision from a missing reply without collecting an entire firewall's traffic.

Sources

Documentation reviewed: 8 October 2026