Cisco ASA Packet Captures for Fun and Profit

by Tony Mattke on March 11, 2013

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 
FW# access-list FOO line 2 extended permit ip host 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 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
1062: 10:53:32.978983 > . 2979731571:2979732951(1380) ack 3788440994 win 8204 
1063: 10:53:32.978999 > . 2979732951:2979734331(1380) ack 3788440994 win 8204 
1064: 10:53:32.979014 > P 2979734331:2979734949(618) ack 3788440994 win 8204 
1065: 10:53:32.982691 > . ack 2979734949 win 16560 
1066: 10:53:34.712441 > 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!

About the author:

Tony Mattke is a network engineer for a financial institution in Indiana. In the past he has worked for ISPs, data centers, networking manufacturers, and the occasional enterprise. For feedback, please leave a comment on the article in question. For everything else including fan mail or death threats, contact him via twitter.

{ 4 comments… read them below or add one }

Ben Story @ntwrk80 March 11, 2013 at 1:25 pm

Although I will be burned at the stake for even mentioning this I will mention it anyway. As someone that has always been in the enterprise space, I often have to troubleshoot ASA problems at the spur of the moment. This led me to embrace the often maligned ASDM GUI for the ASA. The largest reason for this is the Packet Capture wizard and the packet tracer GUI. Being able to click and have the capture file auomatically opened in wireshark is really handy when troubleshooting VPNs and other partner access issues. I also find it easier to setup captures when I need ad hoc ones because I don't have to mess with an ACL if I don't want to.


Rob Gilreath March 11, 2013 at 3:35 pm

Capture and Packet-tracer are CLI commands that you can use as well. Just a matter of knowing the syntax. And like most things, once you know the syntax, it's quicker than the GUI. :)


Rob Gilreath March 11, 2013 at 2:09 pm

Worth noting that with the "no capture NAME" that you should probably do a "no access-list NAME" for the ACL used for the capture. It sucks as a consult to justify the cleanup of TEST1, test, Testing, TEST2, CAPTURE_20090302 when they really should have been removed when the capture was finished.

I use packet captures on the ASA for troubleshooting all the time and the ASP drop captures are great. It's a really powerful tool that stops the need for a span port for most troubleshooting.


Rowell Dionicio March 11, 2013 at 3:12 pm

Wow really nice trick there! This cuts down the time searching through logs w/ more accuracy.

The denied flows is an interesting capture. I may also look into this as a future project.


Leave a Comment

Previous post:

Next post: