This how-to describes the usage of the "capture" feature in Cisco's security products (ASA/PIX, FWSM, IOS). Many scenarios require to monitor the packets across the firewalls. Like we have a host-server communication and somehow the traffic doesn't flow as we want or we have packet-lost. For troubleshooting these issues we have the "capture" command which helps to check what comes in and out.
Where the packet is captured
When we take a capture sometimes we need to know where it is in the packet processing. There are some features which must be before taking the packet.
Virtual Firewall Classification: In multiple context mode there is the possibility of shared interfaces, where ASA needs to determine which physical interfaces assigned to the logical ones. Without this calssification we cannot forward the packet.
Layer 2/3 validation: Obviousely the captures need decoded packets, which contains the l2-l3 header information. If the packet frame is not formated properly we drop the packet and cannot be seen in the capture.
IP packet security check: It checks attacks for TCP, UDP and ICMP
Fragment packet handling: ASA reassemble the packet at this phase.
MAC ACL: if L2 ACLs configured
ASA take the capture
If you apply the capture on an interface without any option or restriction, most probably you won't get a precise data what you look for. Therefore the best approach is to specify the interesting traffic by an ACL. There is no limitation how to deal with the ACLs, you can create for IP to IP or just restrict by protocol.
For this example we are going to use 10.10.10.1 as the client IP, 192.168.0.1 as the server and we want to monitor the HTTP traffic on port 80.
To define the interesting traffic in order to catch it, use this ACL:
As you can see we created two ACL lines, because we need to capture both directions. It is your decision how precise are you in the ACLs, but be careful what you define, may be the traffic is different than you expect.
You can find the full reference about the command "capture" below. There are many options for this command and beside to specify:
You can increase the default buffer by the "buffer" parameter. However you can use the circular-buffer too for continuous capturing.
capture capout access-list cap interface outside buffer 1000000 circular-buffer
Many users have some NAT rules on the firewall which rewrites the packet's IP addresses. You have to take into consideration on which interface which IP addresses you have to use. You cannot use the same capture ACLs on the Inside and Outside interfaces while you do natting, because on Outside interface the IP addresses will be changed.
For example we have the host 126.96.36.199 on the Inside, but it can be seen on the outside as 188.8.131.52. Destination is 184.108.40.206. In this case you need two captures with two different ACL sets, one for the Inside, one for the Outside:
Our NAT rules:
static(inside,outside) 220.127.116.11 18.104.22.168
ASA(config)# access-list cap-inside permit ip host 22.214.171.124 host 126.96.36.199
ASA(config)# access-list cap-inside permit ip host 188.8.131.52 host 184.108.40.206
ASA(config)# access-list cap-outside permit ip host 220.127.116.11 host 18.104.22.168
ASA(config)# access-list cap-outside permit ip host 22.214.171.124 host 126.96.36.199
Collect the captures
If we need the captures for later deep analysis there is a way to grab all the results from the firewall. This lets you open them in Wireshark or other packet analyser softwares. The most common format is PCAP (Packet Capture), which save the traces in a standard format, so any third-party software can read it. By this format you will have all the details about a packet and it is necessary for deep troubleshooting.
There are two ways to download the captures. For example our firewall management interface is 10.0.0.254 and we have done the capture with name "inside_capture".
If you don't need to analyse the captures or view the packet inside, alternatively, you can view them from CLI using the "sh capture" command. For example, following in the 3-way TCP handshake of browsing to the server of our example.
PIX/ASA 7.x, and higher will also let you setup a capture for only dropped packets. This is done with the 'type asp-drop <drop-code>' option. For example:
capture dropped type asp-drop all
This would give you a capture that includes all packets dropped by the firewall. Here is the command reference as well:
Captures taken on an FWSM are not always trustworthy. The reason is that due to a few bugs in the FWSM software versions captures might capture only egress packets thus missing information that is useful for the capture analysis. As an alternative for FWSMs that run span monitoring session on the FWSM's vlans can be used. In more detail,
1. Configure a SPAN monitor port for the ingress and egress VLANs of the FWSM.
Switch# monitor session 2 source vlan 600 , 601 both
This will replicate these two VLANs (vlan 600 and 601 are the outside and inside firewall interfaces in this example) to a third interface/vlan as provided below.
2. Push this data to an external capture device (connection on the switch port FastEthernet 3/1 in this example) running capture software such as Ethereal/Wireshark.
Switch# monitor session 2 destination interface FastEthernet Fa 3/1
3. Captures then can be saved and analysed with the capture software.
In this example we want to check that the HTTP traffic passing trough or not on the firewall.
3. If you want to check the status of the capture, type "show capture"
ASA# show capture
capture capin type raw-data buffer 8000000 [Capturing - 7653 bytes]
capture capout type raw-data buffer 8000000 [Capturing - 7653 bytes]
In this example as you can see we receive and forward traffic on the Inside and Outside interfaces. If you see 0 bytes captured on the Outside interface, it means that either you made a mistake defining the interesting traffic in the ACL or the ASA drops the packets.
4. To view in text format on the ASA itself, type "show capture capin"