07-05-2011 01:01 AM - edited 03-08-2019 06:41 PM
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.
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.
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:
ASA(config)# access-list cap-acl permit tcp host 10.10.10.1 host 192.168.0.1 eq 80
ASA(config)# access-list cap-acl permit tcp host 192.168.0.1 eq 80 host 10.10.10.1
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:
ASA# capture inside_capture interface inside access-list cap-acl
The pattern is something like this:
ASA# capture <name> interface <interface name> access-list <access-list name>
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 1.1.1.1 on the Inside, but it can be seen on the outside as 2.2.2.2. Destination is 8.8.8.8. 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) 2.2.2.2 1.1.1.1
ASA(config)# access-list cap-inside permit ip host 1.1.1.1 host 8.8.8.8
ASA(config)# access-list cap-inside permit ip host 8.8.8.8 host 1.1.1.1
ASA(config)# access-list cap-outside permit ip host 2.2.2.2 host 8.8.8.8
ASA(config)# access-list cap-outside permit ip host 8.8.8.8 host 2.2.2.2
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".
1. Via HTTPS
One is to open your favourite browser and follow this pattern: https://<ip address of firewall>/capture/<context>/<capture_name>/pcap
https://10.0.0.254/capture/inside_capture/pcap
Please note we use secure HTTP (HTTPS) instead of HTTP.
2. Via "copy" command
You can go under the system context and upload them to a tftp server by the "copy" command.
Pattern: "copy /pcap capture:([CONTEXT]/)[NAME] tftp:"
FWSM# copy /pcap capture:inside_capture tftp:
Source capture name [inside_capture]?
Address or name of remote host []? 10.0.0.254
Destination filename [inside_capture]?
!!!!!!!!!!!!!!!!!!
If the capture is configured with a circular buffer and you want to make a copy of the capture at a particular point without disabling the capture, you can run the command below.
FWSM# copy /pcap capture:inside-capture disk0:inside-capture.pcap
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.
ASA# sh capture inside_capture
3 packets captured
1: 18:23:39.364650 802.1Q vlan#100 P0 10.0.0.1.1435 > 192.168.0.1.80: S 1914936295:1914936295(0)
win 65535 <mss 1460,nop,nop,sackOK>
2: 18:23:39.428231 802.1Q vlan#100 P0 192.168.0.1.80 > 10.0.0.1.1435: S 4004665739:4004665739(0)
ack 1914936296 win 8192 <mss 1380>
3: 18:23:39.428353 802.1Q vlan#100 P0 10.0.0.1.1435 > 192.168.0.1.80: . ack 4004665740 win 65535
For more detailed information you can use the "detail" or "dump" option of the command.
Use the "NO" command to remove the captures.
ASA# no capture [NAME OF THE CAPTURE]
Without the "packet-length" parameter you cannot see the full packets in the capture files. You need to extend your command with this option.
ASA# capture inside_capture interface inside access-list cap-acl packet-length 1500
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.
for the inside interface:
access-list cap-inside permit tcp host 192.0.2.100 host 198.18.0.2 eq 80
access-list cap-inside permit tcp host 198.18.0.2 eq 80 host 192.0.2.100
for the outside interface
access-list cap-outside permit tcp host 198.18.0.1 host 198.18.0.2 eq 80
access-list cap-outside permit tcp host 198.18.0.2 eq 80 host 198.18.0.1
2. Start capturing on the interfaces, we need full packets and increased buffer
capture capin access-list cap-inside interface Inside packet-length 1500 buffer 8000000
capture capout access-list cap-outside interface Outside packet-length 1500 buffer 8000000
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"
ASA# show capture capin
24 packets captured
1: 00:53:02.060223 802.1Q vlan#39 P0 192.0.2.100.10522 > 198.18.0.2.80: S 2749700501:2749700501(0) win 5560 <mss 1380,sackOK,timestamp 27240468 0,nop,wscale 7>
2: 00:53:02.101587 802.1Q vlan#39 P0 198.18.0.2.80> 192.0.2.100.10522: S 2333916621:2333916621(0) ack 2749700502 win 5792 <mss 1380,sackOK,timestamp 924355820 27240468,nop,wscale 7>
3: 00:53:02.102320 802.1Q vlan#39 P0 192.0.2.100.10522 > 198.18.0.2.80: . ack 2333916622 win 44 <nop,nop,timestamp 27240472 924355820>
5. You can download the captures by cli command. We are running TFTP server on the client host.
ASA# copy /pcap capture:cap tftp:
Source capture name [cap]?
Address or name of remote host []? 192.0.2.100
Destination filename [cap]? cap.pcap
http://www.cisco.com/en/US/docs/security/asa/asa80/command/reference/c1.html#wp210889
Superlike
10.10.10.1 as the client IP
Is that the assumed IP of the firewall or an external object (i.e. 4.2.2.2) ?
The following is an output from a 5515-X ASA. All attempts to reach the server in the DMZ wither from the LAN or internet isn't possible. I think the issue lies in the DMZ webserver itself. Please, take a look at the capture and suggest.
Thanks in advance.
ciscoasa(config)# show cap
ciscoasa(config)# show capture capo
96 packets captured
1: 11:22:28.518680 41.58.192.110.56382 > 197.253.4.13.80: . 185938744:185938745(1) ack 1999498768 win 668
2: 11:22:28.518909 197.253.4.13.80 > 41.58.192.110.56382: . ack 185938745 win 258 <nop,nop,sack sack 1 {185938744:185938745} >
3: 11:22:56.074535 41.58.192.110.56443 > 197.253.4.13.80: S 225050592:225050592(0) win 8192 <mss 1400,nop,wscale 8,nop,nop,sackOK>
4: 11:22:56.074947 197.253.4.13.80 > 41.58.192.110.56443: S 2143290466:2143290466(0) ack 225050593 win 8192 <mss 1380,nop,wscale 8,nop,nop,sackOK>
5: 11:22:56.096369 41.58.192.110.56382 > 197.253.4.13.80: P 185938745:185939148(403) ack 1999498768 win 668
6: 11:22:56.097147 197.253.4.13.80 > 41.58.192.110.56382: P 1999498768:1999499147(379) ack 185939148 win 257
7: 11:22:56.097407 41.58.192.110.56444 > 197.253.4.13.80: S 3177908077:3177908077(0) win 8192 <mss 1400,nop,wscale 8,nop,nop,sackOK>
8: 11:22:56.097864 197.253.4.13.80 > 41.58.192.110.56444: S 3709476046:3709476046(0) ack 3177908078 win 8192 <mss 1380,nop,wscale 8,nop,nop,sackOK>
9: 11:22:56.124032 41.58.192.110.56443 > 197.253.4.13.80: . ack 2143290467 win 64
10: 11:22:56.139275 41.58.192.110.56382 > 197.253.4.13.80: P 185939148:185939552(404) ack 1999499147 win 666
11: 11:22:56.139305 41.58.192.110.56444 > 197.253.4.13.80: . ack 3709476047 win 64
12: 11:22:56.141029 197.253.4.13.80 > 41.58.192.110.56382: P 1999499147:1999499496(349) ack 185939552 win 255
13: 11:22:56.289337 41.58.192.110.56382 > 197.253.4.13.80: P 185939552:185939971(419) ack 1999499496 win 665
14: 11:22:56.498036 197.253.4.13.80 > 41.58.192.110.56382: . ack 185939971 win 253
15: 11:23:14.245730 41.58.192.110.56443 > 197.253.4.13.80: F 225050593:225050593(0) ack 2143290467 win 64
16: 11:23:14.246157 197.253.4.13.80 > 41.58.192.110.56443: R 2143290467:2143290467(0) ack 225050594 win 0
17: 11:23:14.260347 41.58.192.110.56444 > 197.253.4.13.80: F 3177908078:3177908078(0) ack 3709476047 win 64
18: 11:23:14.260743 197.253.4.13.80 > 41.58.192.110.56444: R 3709476047:3709476047(0) ack 3177908079 win 0
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: