As many of you know my background isn’t in enterprise, but I currently fill that role in my $job. In order to succeed I’ve had to develop many new skills including learning Cisco Wireless, UCS, a little Fibre Channel, and of course Cisco ASA. While I have been using firewalls for many years, I’ve never used the ASA for anything more than a user firewall, or for supporting a small branch. So yes, my skills are lacking in the ASA market compared to other technologies, and when you get deep into the grind with any product you’re going to need some new tricks to aid in your troubleshooting. This is where ASA paacket captures come into place.

Define Interesting Traffic

As with any packet capture, or even log viewing the amount of noise involved generally dwarfs the data you actually want to find. In order to ease your pain Cisco has allowed us filter out packet capture using an ACL.

FW# access-list FOO line 1 extended permit ip any host 10.2.1.5 
FW# access-list FOO line 2 extended permit ip host 10.2.1.5 any 

Once you have your traffic defined, you need to setup your capture. Below I’ve defined a capture named appropriately, FOO, capturing headers from our outside interface that matches our ACL with a 100,000 byte buffer. In ASA 8.0 and above you can do the same capture without the ACL using the match option, which captures traffic bi-directionally.

FW# capture FOO type raw-data access-list CAP buffer 100000 interface outside headers-only
!
! 8.0 and above
FW# capture FOO type raw-data match tcp any host 10.2.1.5 buffer 100000 interface outside headers-only

Viewing your capture

Viewing your capture on the firewall is easy enough using the show capture command. You can do some basic filtering using the built in IOS | include / exclude as well.

FW# sh capture FOO 

1446 packets captured
-snip-
1062: 10:53:32.978983 10.2.1.5.443 > 10.5.3.7.50344: . 2979731571:2979732951(1380) ack 3788440994 win 8204 
1063: 10:53:32.978999 10.2.1.5.443 > 10.5.3.7.50344: . 2979732951:2979734331(1380) ack 3788440994 win 8204 
1064: 10:53:32.979014 10.2.1.5.443 > 10.5.3.7.50344: P 2979734331:2979734949(618) ack 3788440994 win 8204 
1065: 10:53:32.982691 10.5.3.7.50344 > 10.2.1.5.443: . ack 2979734949 win 16560 
1066: 10:53:34.712441 10.5.3.7.50348 > 10.2.1.5.9960: S 3576506984

For more detailed information you can use the detail or dump option with the show command.

While viewing the files on the firewall is handy in a pinch, it is far from your only option. You can also copy the capture off the firewall using tftp or ftp using the copy command copy /pcap capture:FOO tftp:. The firewall exports the capture in PCAP file format, which allows you to retrieve the file and open it up in Wireshark! Although if you don’t run a tftp or ftp server on your desktop, an even handier option may be to simply access the file in your web browser using the following url. https://FIREWALL_IP/capture/FOO/pcap

You need to allow http access from your workstation on the interface you’re entering

Another cool trick is setting up a circular buffer to continually watch interesting traffic. Something I’m using on one of my current projects is a capture that watches for flows that are denied via ACL.

FW# capture denied type asp-drop acl-drop buffer 4194304 circular-buffer headers-only 

Now, once you’re done tracking down what you broke, you probably want to stop the capture, and remove the files. This is done by simply issuing a no capture NAME command from the CLI.

Like I said, I’m not a firewall guru, but this can certainly go a long way to make you look like one to your systems guys when they forget to tell your their web app opens a java client that needs to communicate on TCP/9960….. Not that they’d actually do that or anything.

If any of you have any other cool tricks you can do with ASA Packet Captures please feel free to leave a comment below so I can update the article and give you credit!

{ 3 comments }