Fortigate Packet Sniffer
Rapheal Charlton
Packet capture, also known as sniffing, records some or all of the packets seen by a network interface. By recording packets, you can trace connection states to the exact point at which they fail, which may help you to diagnose some types of problems that are otherwise difficult to detect.
FortiAnalyzer units have a built-in sniffer. Packet capture on FortiAnalyzer units is similar to that of FortiGate units. Packet capture is displayed on the CLI, which you may be able to save to a file for later analysis, depending on your CLI client.
Packet capture can be very resource intensive. To minimize the performance impact on your FortiAnalyzer unit, use packet capture only during periods of minimal traffic, with a serial console CLI connection rather than a Telnet or SSH CLI connection, and be sure to stop the command when you are finished.
Type either none to capture all packets, or type a filter that specifies which protocols and port numbers that you do or do not want to capture, such as 'tcp port 25'. Surround the filter string in quotes.
If you are familiar with the TCP protocol, you may notice that the packets are from the middle of a TCP connection. Because port 22 is used (highlighted above in bold), which is the standard port number for SSH, the packets might be from an SSH session.
The following example captures packets traffic on TCP port 80 (typically HTTP) between two hosts, 192.168.0.1 and 192.168.0.2. The capture uses a low level of verbosity (indicated by 1). Because the filter does not specify either host as the source or destination in the IP header (src or dst), the sniffer captures both forward and reply traffic.
A specific number of packets to capture is not specified. As a result, the packet capture continues until the administrator presses CTRL + C. The sniffer then confirms that five packets were seen by that network interface.
Instead of reading packet capture output directly in your CLI display, you usually should save the output to a plain text file using your CLI client. Saving the output provides several advantages. Packets can arrive more rapidly than you may be able to read them in the buffer of your CLI display, and many protocols transfer data using encodings other than US-ASCII. It is usually preferable to analyze the output by loading it into in a network protocol analyzer application such as Wireshark ( ).
You can convert the plain text file to a format (.pcap) recognizable by Wireshark using the fgt2eth.pl Perl script. To download fgt2eth.pl, see the Fortinet Knowledge Base article Using the FortiOS built-in packet sniffer.
If you literally just want the sniffer output as it appears in the CLI console, then you don't need anything special to do that -- you should be able to just tell your terminal emulator to log the session to a local file on your workstation.
If you want the actual packets, you will need a unit with local storage, and it's a little convoluted to do it from CLI. There are some basic instructions in the cookbook however for how to do what it's capable of, but it's far easier to setup & run the sniffer from the web interface like this. That will get you a pcap file you can easily download from the same web GUI with everything in it.
So we noticed on our 90D and 500Es that we're running into the packet sniffer now showing anything. What looks to be the culprit is that the packets get punted to the ASIC now and when that happens, you see nothing at all.
When you troubleshoot networks and routing in particular, it helps to look inside the headers of packets to determine if they are traveling the route that you expect them to take. Packet sniffing is also known as network tap, packet capture, or logic analyzing.
Before you start sniffing packets, you should prepare to capture the output to a file. A large amount of data may scroll by and you will not be able to see it without saving it first. One method is to use a terminal program like puTTY to connect to the FortiGate CLI. Once the packet sniffing count is reached, you can end the session and analyze the output in the file.
The level of verbosity as one of:
1 - print header of packets
2 - print header and data from IP of packets
3 - print header and data from Ethernet of packets
4 - print header of packets with interface name
This displays the next three packets on the port1 interface using no filtering, and verbose level 1. At this verbosity level, you can see the source IP and port, the destination IP and port, action (such as ack), and sequence numbers.
The following CLI command for a sniffer includes the ARP protocol in the filter which may be useful to troubleshoot a failure in the ARP resolution. For example, PC2 may be down and not responding to the FortiGate ARP requests.
If you select a filter, you have the option to start and stop packet capture in the edit window, or download the captured packets. You can also see the filter status and the number of packets captured.
You can select the filter and start capturing packets. When the filter is running, the number of captured packets increases until it reaches the Max Packet Count or you stop it. You cannot download the output file while the filter is running.
To start, stop, or resume packet capture, use the symbols on the screen. These symbols are the same as those used for audio or video playback. Hover over the symbol to reveal explanatory text. Similarly, to download the *.pcap file, use the download symbol on the screen.
You can download the *.pcap file when the packet capture is complete. You must use a third party application, such as Wireshark, to read *,pcap files. This tool provides you with extensive analytics and the full contents of the packets that were captured.
We're having an issue with a device's traffic not being received by a monitoring service - it should send a UDP 'heartbeat' approximately every 15 seconds. We've done packet captures on the routers/switches along the way and see it everywhere up through the switch port connected to the active Fortigate in our HA pair (active/passive). Running a sniffer on the Fortigate with the proper source IP (diag sniffer packet any 'host x.x.x.x' 4 100 :l ) shows no results though, which seems wrong. I am seeing other traffic from the same subnet passing through the Fortigate, for what its worth.
On the packet capture on the switch I do see that the destination MAC address is the proper virtual MAC of the HA pair, and we have firewall rules in place to permit this traffic. Is there anything else I am missing that can cause us not to see these packets, or are we running in to a weird bug/situation here? Fortigate 300D, version 5.4.5
So the first thing to note is that since FortiGate is such and amazing platform (I know I am biased) and has the advent of ASICs, by default, we do not see the packets that are getting offloaded to the SOC and NOC ASICs. When you are running a capture and are not seeing what you are expecting to see, you may need to disable the offloading on that particular policy.
In the above example, I am looking for ONLY ICMP traffic. In my lab, I have a lot of ICMP traffic so I will filter it further and only choose to capture packets destined to 3.210.115.14 (fortinet.com)
I concluded that the router in front of side B seems to be blocking incoming UDP Port 500 Packets. They did some changes to the router (there did seem to be some issues), the tunnel came back up again and i did a packet sniffer again. Now i was able to see outgoing NAT-T (4500) Packets on SITE B but i did not see the response packets.
e2b47a7662