April 7, 2020

Firewall Troubleshooting :: CLI Packet Captures

(Last Updated On: 27th January 2017)

In this post, I will cover the CLI based packet capture functionality for two firewalls; these are FortiGates and Check Points. Each have slightly different commands, but the results are fairly similar. This post will hopefully be of use for environments with multiple firewalls vendors, or where you support multiple customers with differing firewall vendors.

What is a packet capture?
In this context, the CLI packet capture will ideally show you the traffic ingress or egress an interface at the point of which it touches the specified interface. When I say “touches” I mean when a packet is coming in, you want to see it prior to any modification/processing of that packet, and when it’s going out, you want to see the final packet, after any processing has taken place; this isn’t usually the case as the traffic has to pass through the CPU in order to be displayed in the packet capture, meaning you won’t catch everything and some things may have happened before this point. In the CLI, you will see a list/summary of these packets – most firewalls will support the generation of PCAP files which can then be opened in an application such as WireShark for further investigation.

The FortiGate commans for getting a packet capture is the least familiar to those with experience in Linux. The command is made up of the following components:

Lab-FG # diag sniffer packet <interface> ‘<filter>’ <verbose> <count>

<interface> = The interface on which you want to see the traffic
<filter> = This can be used to target a specific type of traffic (more later)
<verbose> = Level of detail (more later)
<count> = Number of packets to capture

There are three main elements to the filters. These are whether you want to filter on source/destination, what the interesting IP is and what the port/protocol is. You can use a single filter or a combination of all three. An example of a command using a filter is below:

Lab-FG # diag sniffer packet internal ‘src host and dst host and udp port 53’

Your options are src|dst host <ip> and arp|udp|icmp|tcp|esp|gre port <number> (you do not have to specify a port number). You can use “and|or” statements when configuring your filter.

For verbose, you have the following options (taken from the Fortinet KB website)

  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
  5. print header and data from IP of packets with interface name
  6. print header and data from Ethernet of packets with interface name

Example Output

Lab-FG # diag sniffer packet internal1 “src host and dst host and udp port 53” 4 10
interfaces=[internal1] filters=[src host and dst host and udp port 53] 19.598103 internal1192. -> udp 37
19.598222 internal1 — -> udp 43
19.598283 internal1 — -> udp 33
19.599567 internal1 — -> udp 34
19.599661 internal1 — -> udp 33
19.650788 internal1 — -> udp 33
19.650859 internal1 — -> udp 32
22.715083 internal1 — -> udp 33
23.242008 internal1 — -> udp 38
23.379855 internal1 — -> udp 51

The above output is in verbose mode 4, and we can see 5 elements to each line. These represent the following:

  1. This is the time stamp for this packet – you can view the full time stamp by adding an “a” to the end of the sniffer command (e.g. diag sniffer packet any none 4 10 a)
  2. This is the interface on which the packet is seen – as we have filtered to just “internal1” all packets in our output will be on internal1
  3. Here we have the source IP address and source port
  4. Here we have the destination IP address and destination port – DNS (UDP 53) in this example 
  5. UDP Length  

Note 1: This output is taken on a FortiGate 80C running FortiOS 5.4.1
Note 2: Most FortiGates have “Network Processors” for ASIC acceleration. When packets are being accelerated, you will not see them in this output.
Note 3: Do use this command with caution. If the box is under heavy load, it may be best not to use this, as all this information is gathered at the CPU. Filtering will help here, but I have seen a FortiGate crash whilst using this command.

Check Point
To capture packets on the CLI on a Check Point device, we use the TCPDump Linux tool. You must be within expert mode on the Check Point device to run this command; which can be achieved by typing expert and entering the expert password. Alternatively you can set a user to use /bin/bash as their default shell – this can be done using the command chsh -s username /bin/bash from within expert mode, or you can edit the user shell through the GAiA WebUI. As a common Linux tool, tcpdump is well documented on the internet, but I will cover the basics in this post.

There’s far more we could do with TCPDump in Linux that I will go in to. For the purpose of this post, I will focus on output similar to that of the FortiGate equivalent – which is useful enough for some quick troubleshooting. An example command would be built up of the following components:

[[email protected]] # tcpdump <switches><interface> <filter>

<switches> = There are plenty of “switches” you can add to modify the output, for example, “-n” would disable DNS resolution of IPs and “-i” is used when you are going to define an interface
= This is the interface on which you want to run the packet capture, whether egress or ingress – this would be preceded by the “-i” switch
 = This is the filter you would use to tie down the output you get

As with the FortiGate, there are a number of filter you can use. As this is only a brief overview on each appliance, I will cover some of the obvious ones. Here is an example command you could run:

[[email protected]] # tcpdump -ni eth1 src host and dst host and port 53

As you can see, the filters are not at all dissimilar to those used on the FortiGate – do also note that I have combined the “-n” and “-i” switches together. As it’s a Linux utility, you can easily find further information on tcpdump across the internet.

My plan here was to add some output from a Check Point firewall, however, I don’t currently have a Check Point set up in my lab. I will rectify this in the near future and revisit this post, providing you with some output and breaking it down in a similar fashion to how I have done it with the FortiGate output. When I come to revisit this post, I also intend to add a tcpdump output from a Palo Alto firewall.

For now, I hope you’ve found this post useful and that you find use for some of our other posts.



Previous «
Next »

Jake is a security engineer working in West Yorkshire. He has experience with various firewall vendors including FortiGate, Check Point, Cisco and Palo Alto.

Leave a Reply

Subscribe to SYNACK via Email

%d bloggers like this: