|
On the source FortiGate, approximately 1000 packets are captured using a host A ↔ host B filter.
On the destination FortiGate, the live sniffer displays no traffic; however, after the sniffer is stopped, a small non-zero packet count is reported.
There are two counters at the end of a sniffer. 'Packets received by filter' is the total amount of packets which hit the filter.
'packets dropped by kernel' are packets included in the previous total, but which were not shown for whatever reason. This is not due to the NPU. Packets which are handled by the NPU do not make it to the kernel in the first place, and are not included in this value.
Potential root causes and what to try:
- The sniffer counts packets, but the console does not print them (pager/buffering). In some SSH sessions, the console pager or output buffering prevents live lines from rendering; on stop, only the summary is visible.
Before sniffing:
config system console
set output standard
set line-edit disable
end
Run the sniffer with DNS disabled so output flows freely:
diagnose sniffer packet any 'host <SRC> and host <DST>' 3 0 n
- Wrong VDOM or wrong interface view (port-channel/VLAN/SDN constructs). It is common to have multiple VDOMs (e.g., root and tenant) and sub‑interfaces. Running the sniffer in the wrong VDOM or on a different sub‑interface than where traffic actually traverses, it is possible to see a rising counter but no printed lines for filter view.
Quick checks:
get system status | grep -i vdom
get system interface | grep -e port -e vlan -e aggregate
Switch to the correct VDOM, then run:
config vdom
edit <vdom>
end
diagnose sniffer packet any 'host <SRC> and host <DST>' 3 0 n
Try binding to the exact interface (e.g., port1, port1.100, agg1), not only 'any'.
- Accelerated Networking/fast‑path (no physical NPU) → classic sniffer may not show all packets live
Workarounds:
Temporarily force the session through CPU using a test policy (only for validation):
config firewall policy
edit <ID_of_matching_policy>
set np-acceleration disable
set auto-asic-offload disable
next
end
- Console cannot keep up with bursts (print drops while counter is accurate). With short bursts, FortiOS may not render every packet to the terminal, even though the capture engine counted them.
Mitigations:
Use verbosity 3 (headers) rather than 4/6 (payload), and disable DNS resolution:
diagnose sniffer packet any 'host <SRC> and host <DST>' 3 0 n
Capture to file as in #3 and arrow the filter (single port/flag) to reduce PPS.
- Encapsulations change what filter matches (VXLAN/ERSPAN/ALG). If the path uses VXLAN (UDP/4789), ERSPAN, or an ALG (e.g., SIP, FTP) that introduces ephemeral port changes, a plain host SRC and host DST filter may not hit the outer headers actually observing.
Examples:
VXLAN underlay:
diagnose sniffer packet <underlay_intf> 'udp port 4789 and (host <A> and host <B>)' 3 0 n
ERSPAN:
diagnose sniffer packet <wan_interface> 'proto 47 or proto 50 or tcp port 4747' 3 0 n
- Routing asymmetry: packets never reach the destination FortiGate. Misapplied or peering settings (e.g., 'propagate gateway routes' disabled) can make the source send ~1000 packets while the destination FortiGate never receives them. The destination sniffer then only counts a handful of unrelated frames (e.g., ARP/ICMP) and prints nothing matching the filter.
Validate with debug flow on the destination:
diagnose debug reset
diagnose debug flow filter clear
diagnose debug flow filter saddr <SRC>
diagnose debug flow filter daddr <DST>
diagnose debug flow show function-name enable
diagnose debug flow trace start 100
diagnose debug enable
Reproduce for 10–20s, to stop.
diagnose debug disable
If no received traces, the traffic is not reaching this FortiGate; check UDR/NSG/LB in front of it.
Related articles:
|
