Fortinet devices include a built-in sniffer that you can use for debugging purposes
The following are suggestions to improve the usability of this tool.
Try to always include ICMP in the sniffer filter. You may capture an ICMP error message that can help identify the cause of the problem.
For example, diag sniff packet interface wan1 ‘tcp port 3389 or icmp’ 3
You can use the “any” interface if you want to confirm that a specific packet is received or sent by the Fortinet device, without specifically knowing on which interface this may be. This will essentially enable the sniffer for all interfaces.
For example, diag sniff packet interface any ‘tcp port 3389’ 3
The Fortinet device may not display all packets if too much information is requested to be displayed, or the traffic being sniffed is significant. When this occurs, the unit will log the following message once the trace is terminated:
12151 packets received by filter
3264 packets dropped by kernel
When this occurs, it is possible that what you were attempting to capture was not actually captured. In order to avoid this, you may try to tighten the display filters, reduce the verbose level, or perform the trace during a lower traffic period.
The packet timestamps as displayed by the sniffer, may become skewed or delayed under high load conditions. This may occur, even if no packets were dropped (as mentioned above). Therefore, it is not recommended that you rely on these values in order to troubleshoot or measure performance issues, that would require absolute precise timing.
Enabling the sniffer will consume additional CPU resources. This can be as high as an additional 25% of CPU usage on low-end models. Therefore enabling this on a unit that is experiencing excessively high CPU usage can only render the situation worse. If you must perform a sniff, keep the sniffing sessions short.
Older versions of FortiOS could cause a memory usage leak if a sniffer trace was enabled using a telnet or SSH session, and this session terminated (due to timeout) prior to ending the sniffer (with Ctl-C). When this occurred, the sniffed process would remain stuck in the process list, and would continue to hold on to its allocated memory. This is visible by using the diag sys top command, and can be corrected by killing the orphaned processes with a diag sys kill command. This problem was fixed in version 2.80MR10 or later.
Short Ethernet frames sent by the FortiGate may appear to be under the minimum length of 64 bytes (also known as “runts”). This is because the sniffer does not display any Ethernet Trailer/Padding information, although it is sent on the wire.
The Ethernet source and/or destination MAC addresses may be incorrect when using the “any” interface. They may be displayed as all zeros (00:00:00:00:00:00) or 00:00:00:00:00:01
future of cybersecurity 