FortiGate · FortiOS 7.4

FortiGate packet capture commands and useful filters

Quick answer #

Use a filtered, finite packet capture to answer a concrete question: does the request arrive, which interface carries it onward, and does a response return? Start with interface names and packet headers. Increase capture detail only when the investigation requires payload information.

Scope: FortiGate/FortiOS 7.4-family CLI; IPv4 examples. Output visibility depends on acceleration and platform.

Capture one client connection #

In the traffic VDOM, replace the sample client and run:

Capture one client connection
FortiOS 7.4 · Traffic VDOM; administrative scope as described below

Diagnostic state

Replace these example values: 10.20.30.40.

diagnose sniffer packet any 'host 10.20.30.40 and tcp port 443' 4 100 l

Press Ctrl+C when finished; a packet-count limit is not a time limit.

Output may contain sensitive operational data.

This stops after 100 matching observations. Press Ctrl+C to stop earlier, including when the filter matches nothing. Level 4 includes interface information. The final l requests local timestamps; use a for UTC when correlating devices across time zones. A packet limit is not a time limit: an idle flow can leave the capture waiting.

Use the smallest useful filter #

Choose one of these independent examples rather than pasting them as a batch:

Use the smallest useful filter
FortiOS 7.4 · Traffic VDOM; administrative scope as described below

Diagnostic state

Replace these example values: 192.0.2.80.

diagnose sniffer packet any 'host 192.0.2.80 and tcp port 443' 4 100 l

Press Ctrl+C when finished; a packet-count limit is not a time limit.

Output may contain sensitive operational data.
Diagnostic state

Replace these example values: 10.20.30.40.

diagnose sniffer packet any 'host 10.20.30.40 and icmp' 4 40 l

Press Ctrl+C when finished; a packet-count limit is not a time limit.

Output may contain sensitive operational data.
Diagnostic state

Replace these example values: wan1.

diagnose sniffer packet wan1 'arp' 4 30 l

Press Ctrl+C when finished; a packet-count limit is not a time limit.

Output may contain sensitive operational data.

For source-NAT traffic, a client-address filter may show the inside leg but miss the translated outside leg. A destination-and-port filter often preserves visibility across that boundary. With destination NAT, make an explicit note of both the public and private destination before choosing the filter.

Read the result as a path #

Write down ingress interface, original tuple, egress interface and visible return traffic. A request arriving on the expected VLAN but never appearing at the expected uplink narrows the next check to routing, policy or packet visibility. A request leaving with no visible response directs attention toward the return path and remote endpoint. Neither observation proves a firewall defect by itself.

Do not equate each printed line with a unique application packet: capturing on any can show the same packet at multiple observation points. Likewise, an empty capture is not proof that an accelerated session has stopped forwarding. Compare a newly initiated connection with the session table before changing anything.

Keep a useful record #

Save the filter, VDOM, test time, client address and one clearly identified attempt with the output. Capture narrowly enough to avoid collecting unrelated users' data. For a transferable PCAP, use the platform's GUI packet-capture feature when available; terminal text is not itself a PCAP file.

Sources

Documentation reviewed: 8 October 2026