PACKET TRACER AND CAPTURE ON ASA

Firewall configurations can be tricky to debug. Especially when you think you have all the proper NAT statements, route statements, and access control lists in place, and it’s still not working quite as you had planned. Have no fear, Packet Trace is here!

The Cisco ASA Packet Trace feature is a wonderful tool for finding out just how a packet will be handled by your ASA in its current configuration. The Packet Trace feature allows you to select an interface, then supply a couple of IP addresses and ports, and it will then trace the path that packet will take through your firewall and provide detailed results.

This tool can be accessed in a couple of different places via the Cisco ASDM. One of these places is in the Firewall’configuration screen on the NAT Rules tab. You’ll see it near the top on the right-hand display.

Here is a screen shot of the initial packet trace setup.

Figure A

NOTE: Click to enlarge.

In Figure B, I’ve set up a trace for an internal IP going to an external Web site. As the packet is processed by the firewall, the individual steps are displayed in real time if you have the Show Animation box selected. These steps are further detailed in the Phase portion of the display. In the example, the results show that the firewall rules will allow this traffic as each step of the process is given a green check mark and the final results are reported as “The packet is allowed.”

Figure B

NOTE: Click to enlarge.

You can drill down into each phase of the process to see exactly what steps were taken, which ACLs were used in processing the packet, what route was used, etc. Figures C, D, and E show the actual packet path and processing of our example flow.

In Figure C, we see the packet go through an access list check, a check for any existing matching traffic flows, and a valid route check.

Figure C

NOTE: Click to enlarge.

In Figure D, we see the NAT translation rules that are applied to this packet and the resulting dynamic translation (PAT) that is used.

Figure D

NOTE: Click to enlarge.

In Figure E, you can see that a Flow is created, its flow ID number, and the route that has been selected as well as the final result.

Figure E

NOTE: Click to enlarge.

The final example shows a flow that was not allowed through the firewall.

Figure F

NOTE: Click to enlarge.

As you can see from the above information, this simply wonderful tool can provide a wealth of information. This comes in handy whether you are debugging a critical issue, checking an access control list, or settling your curiousity about how your firewall is actually processing packets.

Easy packet captures straight from the Cisco ASA firewall

Whether you are troubleshooting a difficult problem or chasing some interesting traffic, sometimes you need to pull a packet capture. Of course, you could configure and deploy a sniffer, but that is not the only solution you have at your fingertips. You can pull the packet capture directly from the Cisco ASA firewall. The Cisco ASA makes this an easy process.

There are at least two ways to configure your ASA to capture packets. If you prefer the GUI interface of the ASDM, you can use the Packet Capture Wizard tool by selecting it from the wizard menu.

However, I’ve found that if you don’t mind getting your hands dirty, so to speak, the CLI interface is the way to go. You can identify the traffic you are looking for with an ACL and then set your interface to capture based on the ACL results. Here’s an example of how easy it is to do this.

In this example, I want to capture all IP packets between a host at 192.168.80.51 and the test ASA at 192.168.81.52.

The first step is to set a quick ACL:

access-list testcap extended permit ip host 192.168.80.51 host 192.168.81.52

Then, we set up the capture using the capture command. We’ll reference our ACL (testcap) as our “interesting” traffic, and we’ll specify which interface we want to look at:

myasa# capture testcap interface inside

Admittedly, this is probably the command in its simplest form. There are many options you can configure as part of this command, including setting buffer sizes, setting a circular-buffer that overwrites itself when full, and selecting webvpn or isakmp traffic. The point is, with two quick commands, we’ve got a packet capture going! It just doesn’t get much easier than that.

A quick show capture command verifies my capture is running.

myasa# sh capture

capture testcap type raw-data interface INSIDE [Capturing - 4314 bytes]

To stop the capture, use the no form of this command.

myasa # no capture testcap

Now let’s look at the results. Here again, we have choices. We can look at the traffic via a browser directly from the ASA by opening an http link (Figure A) like the following:

https://192.168.81.52/admin/capture/testcap

Figure A

Click to enlarge.

While we see the traffic and much of the information, we cannot see all the detail of a regular packet capture. However, we can save this info as a libpcap file with the following command, and then open this file with Wireshark or such.

https://192.168.81.52/capture/testcap/pcap

Figure B shows this file when opened with Wireshark.

Figure B

Click to enlarge.

The command line also provides options for looking at your data.

myasa# show capture testcap ?

  access-list    Display packets matching access list

  count          Display <number> of packets in capture

  decode         Display decode information for each packet

  detail         Display more information for each packet

  dump           Display hex dump for each packet

  packet-number  Display packet <number> in capture

  trace          Display extended trace information for each packet

  |              Output modifiers

  <cr>

Let’s look at the first nine packets.

myasa# show capture testcap count 9

4532 packets captured

   1: 13:46:31.052746 192.168.81.52.22 > 192.168.80.51.2057: P 1290581619:1290581687(68) ack 941116409 win 8192

   2: 13:46:31.052884 192.168.80.51.2057 > 192.168.81.52.22: . ack 1290581687 win 65207

   3: 13:46:38.374583 arp who-has 192.168.80.219 tell 192.168.82.51

   4: 13:46:38.521655 arp who-has 192.168.80.204 tell 192.168.82.51

   5: 13:46:39.803120 192.168.81.52.443 > 192.168.80.51.3968: P 787673978:787675438(1460) ack 3043311886 win 8192

   6: 13:46:39.803150 192.168.81.52.443 > 192.168.80.51.3968: P 787675438:787675589(151) ack 3043311886 win 8192

   7: 13:46:39.803257 192.168.81.52.443 > 192.168.80.51.3968: P 787675589:787677049(1460) ack 3043311886 win 8192

   8: 13:46:39.803272 192.168.81.52.443 > 192.168.80.51.3968: P 787677049:787677200(151) ack 3043311886 win 8192

   9: 13:46:39.803287 192.168.81.52.443 > 192.168.80.51.3968: P 787677200:787677883(683) ack 3043311886 win 8192

9 packets shown

We can also look at an entire packet from the CLI.

myasa# show capture testcap detail packet-number 5 dump

4532 packets captured

   5: 13:46:39.803120 0022.5597.25b9 0014.3815.89fb 0x0800 1514: 192.168.81.52.443 > 192.168.80.51.3968: P [tcp sum ok] 787673978:787675438(1460) ack 30                   43311886 win 8192 (ttl 255, id 54032)

0x0000   4500 05dc d310 0000 ff06 c052 c0a8 5134        E..........R..Q4

0x0010   c0a8 5033 01bb 0f80 2ef2 f37a b565 410e        ..P3.......z.eA.

0x0020   5018 2000 5488 0000 1703 0106 4654 db31        P. .T.......FT.1

0x0030   b3d4 0a5b 3295 f719 d82a 8767 6b8b dae1        ...[2....*.gk...

0x0040   0a54 0ea8 c8c4 1c61 c45c e321 452e 6ab6        .T.....a.\.!E.j.

0x0050   ba80 4e94 3801 d973 b4fe 97d4 8b2f 9e77        ..N.8..s...../.w

*Only a partial result is displayed.

So save your hardware or laptop sniffers for other parts of your network. Use your ASA to gather those snippets of network traffic that you need. But remember: in general, be kind to your ASA. When possible, create specific ACLs to refine the traffic you want to capture. Monitor your ASA while capturing packets and adjust the buffers if you need to. And, as always, refer towww.cisco.com for more detailed information.