There are many situations where you need to be able to capture traffic at ANY point in the network. Whether it testing from the client side, server side, or any transit component, such as your ASA. Since the traditional tools such as tcpdump or Wireshark aren't available, you will have to use the proprietary tools on the ASA itself.

You will start off by creating an ACL to match the traffic you are wanting to capture. This should be a strict, such as a source and dest that are experiencing the issues you are troubleshooting:

access-list test.capacl extended permit ip host 192.168.0.10 host 10.5.5.1
access-list test.capacl extended permit ip host 10.5.5.1  host 192.168.0.10

Now that you have configured the access list to match your traffic, you can start the capture. I am capturing traffic before and after it goes over the VPN, so I will monitor the interface closest to the source, which is the 'inside' interface. There aren't any "required"; options besides the name but if you don't specify an ACL and interface, you won't match any traffic. There are a few options you may want to use other than those two:

  • type (default is raw-data but there are other options such as ISAKMP)
  • headers-only (no data, just headers; similar to tcpdump -q)
  • buffer (default is 512KB. Increase with caution, you don't want to use up all your memory)
  • real-time (have output display in your terminal)
  • *more* - use 'capture <cap_name> ?' to see all options

We will go with the basics; access-list and interface:

fw01# capture test-cap access-list test.capacl interface inside

After this, you can check your console to see if the traffic is matching your ACL and being captured with 'show capture'; if the bytes are a non-zero value and increasing, it's working!

fw01# show capture
capture test-cap type raw-data access-list test.capacl interface inside [Capturing - 1560 bytes]

If you want to see the content, you have to specify the capture name:

fw01# show capture test-cap

12 packets captured

   1: 01:47:27.675914       802.1Q vlan#100 P0 192.168.0.10 > 10.5.5.1: icmp: echo request 
   2: 01:47:27.761236       802.1Q vlan#100 P0 10.5.5.1 > 192.168.0.10: icmp: echo reply 
   3: 01:47:28.678431       802.1Q vlan#100 P0 192.168.0.10 > 10.5.5.1: icmp: echo request 
   4: 01:47:28.763708       802.1Q vlan#100 P0 10.5.5.1 > 192.168.0.10: icmp: echo reply 
   5: 01:47:29.688425       802.1Q vlan#100 P0 192.168.0.10 > 10.5.5.1: icmp: echo request 
   6: 01:47:29.773687       802.1Q vlan#100 P0 10.5.5.1 > 192.168.0.10: icmp: echo reply 
   7: 01:47:30.693262       802.1Q vlan#100 P0 192.168.0.10 > 10.5.5.1: icmp: echo request 
   8: 01:47:30.778493       802.1Q vlan#100 P0 10.5.5.1 > 192.168.0.10: icmp: echo reply 
   9: 01:47:31.695703       802.1Q vlan#100 P0 192.168.0.10 > 10.5.5.1: icmp: echo request 
  10: 01:47:31.781011       802.1Q vlan#100 P0 10.5.5.1 > 192.168.0.10: icmp: echo reply 
  11: 01:47:32.698999       802.1Q vlan#100 P0 192.168.0.10 > 10.5.5.1: icmp: echo request 
  12: 01:47:32.784184       802.1Q vlan#100 P0 10.5.5.1 > 192.168.0.10: icmp: echo reply 
12 packets shown

So if you were troubleshooting connectivity and you see this successful ICMP traffic, the loss you are experiencing must be somewhere else. Now you can assure that packets are hitting the firewall and this should help you verify your high level packet flow, to hopefully pinpoint where the issue is. If you want to see more information, there are a few more useful options when displaying the capture:

  • access-list (yes, you can use an additional access-list to filter the output of 'show capture')
  • count (# of packets to display)
  • detail (display more information such as TTL, DF bit, etc)
  • dump (display the hex dump for each packet)
  • *more* - use 'show capture <cap_name> ?' to view all options

So if you would like to view the hex dump of 1 packet, you can with:

fw01# show capture cap-test count 1 dump

60 packets captured

   1: 01:47:27.675914       802.1Q vlan#100 P0 192.168.0.10 > 10.5.5.1: icmp: echo request
0x0000	 c08c 608c 2990 0050 569c 4211 8100 000a	..`.)..PV.B.....
0x0010	 0800 4500 0060 0000 4000 4001 a9a6 c0a8	..E..`..@.@.....
0x0020	 0a87 c0a8 051f 0800 74cd 5122 0000 0000	........t.Q"....
0x0030	 0000 0000 0000 af71 2c55 0000 0000 4c49	.......q,U....LI
0x0040	 0a00 0000 0000 0000 0000 0000 0000 0000	................
0x0050	 0000 0000 0000 0000 0000 0000 0000 0000	................
0x0060	 0000 0000 0000 0000 0000 0000 0000 0000	................
0x0070	 0000                                   	.. 
1 packet shown

Often, you may have a large capture and you don't want to sift through it on the ASA. You might want to look at the capture file in wireshark or tcpdump. You can do so by copying the file via tftp to a workstation or server. But how will the output be formatted... with just headers, hex dumps or .. ? Well, when you transfer it via copy, you specify to use pcap format, which you will be able to read in just about any packet analysis program as it is the most commonly used. You can do this via:

fw01# copy /pcap capture:cap-test tftp:TFTP-SERVER-IP

Awesome! So although the ASA capture utility isn't as versatile as tcpdump or wireshark for example, it is still great to start with and verify packet flow, etc. And if you want to save a larger capture for future analysis, it can be copied and opened with another packet analysis tool. From there you can use your advanced filters, etc.

I hope you enjoyed the basic tutorial on how to use the ASA capture utility... perhaps soon I will write one up on how to effectively use packet-tracer, which is yet another useful ASA command line tool for verifying packet flow and it will also give you a better understanding of how the ASA processes packets. (order of NAT/ACL processing, route lookup, etc.)

Cheers!