One of my favorite troubleshooting tools on the Cisco ASA firewall is doing a packet capture. An incoming packet will hit the capture before any ACL or NAT or other processing. An outgoing packet will hit a capture last before being put on the wire.
Starting the Capture
To start a packet capture from the CLI execute the following command:
An example capture may look like this:
That will capture any traffic coming from 22.214.171.124 going to 126.96.36.199 as a destination on any port. Also, it will capture the opposite too. Traffic coming from 188.8.131.52 going to 184.108.40.206 will be captured.
Viewing the Capture
There are two ways to view what you have captured.
Getting the pcap file
You can download the pcap file to examine it in wireshark. There are two ways to get the pcap file off the ASA.
Download pcap file from ASDM
Use a web browser and go to to your firewall’s IP with a specific URL:
Download pcap from CLI
It is also possible to move a file from the ASA to a FTP server using this command:
copy /pcap capture:CAP1 ftp://user:email@example.com/CAP1.pcap
Viewing the output at the CLI
To see what has been captures issue the following command from the CLI:
show capture CAP1
The capture output for a TCP flow follows this template:
HH:MM:SS.ms [ether-hdr] src-addr.src-port dest-addr.dst-port: tcp-flags [header-check] [checksum-info] sequence-number ack-number tcp-window urgent-info tcp-options
Let’s look more closely into what the ‘tcp-flags’ can show us.
Here is an example TCP capture broken down.
User 220.127.116.11 is accessing the website located at 18.104.22.168.
1: 15:01:45.052762 22.214.171.124.12869 > 126.96.36.199.80: S 3624439037:3624439037(0) win 8192
The S here indicates this is a SYN.
2: 15:01:45.053403 188.8.131.52.80 > 184.108.40.206.12869: S 285283040:285283040(0) ack 3624439038 win 8192
This packet has both a S (syn) and an ack. Notice here the source of this packet is the webserver 220.127.116.11. To really tell who initiated this flow originally look at the ports. You see that the source IP is coming from port 80 and its going to port 12869. This tells us this is return traffic and the original request was really TO port 80.
3: 15:01:45.054501 18.104.22.168.12869 > 22.214.171.124.80: . ack 285283041 win 260
Here is the ack. This signifies the completion of the 3 way handshake. If you see this in the capture you know that communication is taking place properly.
4: 15:01:45.054852 126.96.36.199.12869 > 188.8.131.52.80: P 3624439038:3624439328(290) ack 285283041 win 260
Now the requester is sending a Push. This means show me the data!
5: 15:01:45.244463 184.108.40.206.80 > 220.127.116.11.12869: . ack 3624439328 win 260
The next packet is another ack. The webserver says ok, I got your push.
6: 15:01:46.344296 18.104.22.168.80 > 22.214.171.124.12869: . 285283041:285284301(1260) ack 3624439328 win 260
7: 15:01:46.344418 126.96.36.199.80 > 188.8.131.52.12869: . 285284301:285285561(1260) ack 3624439328 win 260
Look carefully here. The header check here is simply . which indicates data being sent. And it makes sense that data is being sent from the webserver to the user.
“Clearing” the capture refers to getting rid of the data in the capture. To do this, issue the following command:
clear capture CAP1
“Removing” a capture means to delete its contents and the listener from the ASA. To do this, issue this command:
no capture CAP1