How to perform a sniffer trace (CLI and Packet Capture)
When troubleshooting networks and routing in particular, it helps to look inside the headers of packets to determine if they are traveling along the expected route. Packet sniffing can also be called a network tap, packet capture, or logic analyzing.
If your FortiGate unit has NP2/NP4 interfaces that are offloading traffic, this will change the sniffer trace. Before performing a trace on any NP2/NP4 interfaces, you should disable offloading on those interfaces.
What can sniffing packets tell you
If you are running a constant traffic application such as ping, packet sniffing can tell you if the traffic is reaching the destination, what the port of entry is on the FortiGate unit, if the ARP resolution is correct, and if the traffic is being sent back to the source as expected.
Sniffing packets can also tell you if the FortiGate unit is silently dropping packets for reasons such as Reverse Path Forwarding (RPF), also called Anti Spoofing, which prevents an IP packet from being forwarded if its Source IP does not either belong to a locally attached subnet (local interface), or be part of the routing between the FortiGate unit and another source (static route, RIP, OSPF, BGP). Note that RPF can be disabled by turning on asymmetric routing in the CLI (config system setting, set asymetric enable), however this will disable stateful inspection on the FortiGate unit and cause many features to be turned off.
If you configure virtual IP addresses on your FortiGate unit, it will use those addresses in preference to the physical IP addresses. You will notice this when you are sniffing packets because all the traffic will be using the virtual IP addresses. This is due to the ARP update that is sent out when the VIP address is configured.
How do you sniff packets
The general form of the internal FortiOS packet sniffer command is:
diag sniffer packet <interface_name> <‘filter’> <verbose> <count>
To stop the sniffer, type CTRL+C.
<interface_name> The name of the interface to sniff, such as “port1” or “internal”. This can also be “any” to sniff all interfaces.
<‘filter’>
What to look for in the information the sniffer reads. “none” indicates no fil- tering, and all packets will be displayed as the other arguments indicate.
The filter must be inside single quotes (‘).
<verbose> 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
<count> The number of packets the sniffer reads before stopping. If you do not put a number here, the sniffer will run forever unit you stop it with <CTRL C>.
For a simple sniffing example, enter the CLI command diag sniffer packet port1 none 1 3. This will display the next three packets on the port1 interface using no filtering, and using 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.
In the output below, port 443 indicates these are HTTPS packets, and 172.20.120.17 is both sending and receiving traffic.
Head_Office_620b # diag sniffer packet port1 none 1 3 interfaces=[port1] filters=[none]
0.545306 172.20.120.17.52989 -> 172.20.120.141.443: psh 3177924955 ack 1854307757
0.545963 172.20.120.141.443 -> 172.20.120.17.52989: psh 1854307757 ack 3177925808
0.562409 172.20.120.17.52988 -> 172.20.120.141.443: psh 4225311614 ack 3314279933
For a more advanced example of packet sniffing, the following commands will report packets on any interface travelling between a computer with the host name of “PC1” and the computer with the host name of “PC2”. With verbosity 4 and above, the sniffer trace will display the interface names where traffic enters or leaves the FortiGate unit. Remember to stop the sniffer, type CTRL+C.
FGT# diagnose sniffer packet any “host <PC1> or host <PC2>” 4
or
FGT# diagnose sniffer packet any “(host <PC1> or host <PC2>) and icmp” 4
The following sniffer CLI command includes the ARP protocol in the filter which may be useful to troubleshoot a failure in the ARP resolution (for instance PC2 may be down and not responding to the FortiGate ARP requests).
FGT# diagnose sniffer packet any “host <PC1> or host <PC2> or arp” 4
Packet Capture
When troubleshooting networks, it helps to look inside the header of the packets. This helps to determine if the packets, route, and destination are all what you expect. Packet capture can also be called a network tap, packet sniffing, or logic analyzing.
To use the packet capture:
1. Go to System > Network > Packet Capture.
2. Select the interface to monitor and select the number of packets to keep.
3. Select Enable Filters.
4. Enter the information you want to gather from the packet capture.
5. Select OK.
To run the capture, select the play button in the progress column in the packet capture list. If not active, Not Running will also appear in the column cell. The progress bar will indicate the status of the capture. You can stop and restart it at any time.
When the capture is complete, click the Download icon to save the packet capture file to your hard disk for further analysis.
Packet capture tells you what is happening on the network at a low level. This can be very useful for troubleshooting problems, such as:
- Finding missing traffic.
- Seeing if sessions are setting up properly.
- Locating ARP problems such as broadcast storm sources and causes.
- Confirming which address a computer is using on the network if they have multiple addresses or are on multiple networks.
- Confirming routing is working as you expect.
- Wireless client connection problems.
- Intermittent missing PING packets.
- A particular type of packet is having problems, such as UDP, which is commonly used for streaming video.
If you are running a constant traffic application such as ping, packet capture can tell you if the traffic is reaching the destination, how the port enters and exits the FortiGate unit, if the ARP resolution is correct, and if the traffic is returning to the source as expected. You can also use packet switching to verify that NAT or other configuration is translating addresses or routing traffic the way that you want it to.
Before you start capturing packets, you need to have a good idea of what you are looking for. Capture is used to confirm or deny your ideas about what is happening on the network. If you try capture without a plan to narrow your search, you could end up with too much data to effectively analyze. On the other hand, you need to capture enough packets to really understand all of the patterns and behavior that you are looking for.
Hi,
How can we capture packets based on policy ID in forinet, as we can see in ‘diag sniffer’ command there is no option of specifying policy-ID.
The best way would be to just do a diag based on the most refined filter you can do. The only time I look at policy ID’s is when I’m looking through diag debugs…sniffer I set the source, destination, interfaces, and ports to tie down the flow I need. Launch two putty sessions….log both and do source and destination filter on one and flip those for the other (to see the other direction). Should give you more than what you need.
How resolve dst IP?
You are asking how to filter based on the destination IP?
Is it possible to put an FQDN instead of IP?
I want to sniff our main Fortigate for ports used for external IP phones and softclients from IP 10.0.0.240
On a 60D with no vdoms I see no Network tab under System. Only the Network tab on the main bar. Neither have a Packet capture subtab.
Is it possible to configure a diag sniff filter to only capture rtcp sender reports and receiver reports?
I would like to use information in the reports to troubleshoot an intermittent voip quality issue.