Have you experienced traffic destined through a Cisco ASA firewall disappears and you do not know if the traffic stops in the firewall or somewhere else? The solution is the capture feature. This feature was released in 6.2(1) and works in all firewalls modes; routed, transparent and multiple contexts. So, what does the capture feature / command do? The answer is simple... The capture feature can capture traffic on interfaces that can be analyzed in either the CLI or in Wireshark since it produces a pcap file. If you have never used Wireshark, it is a great tool for this type of analysis.
Scenario
Let’s test this; here we have a simple scenario with one computer connected on the inside of a firewall and a server connected to the outside of the firewall.
Scenario
Let’s test this; here we have a simple scenario with one computer connected on the inside of a firewall and a server connected to the outside of the firewall.
Our problem is that we can’t ping the server from the host but it’s pingable from the ASA. This scenario is built in GNS3 with routers posing as inside host and outside server.
inside_host#ping 192.168.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/35/80 ms
inside_host#ping 10.0.0.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.10, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
ASA1# ping 192.168.0.52
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.52, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/14/50 ms
ASA1# ping 10.0.0.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 10/16/30 ms
outside_server#ping 10.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/32/100 ms
Troubleshooting
To use capture to help us solve this problem we have to take four steps:
- 1
- Recognize the interested traffic in an access-list
- 2
- Apply the access-list to a capture process and apply it to an interface
- 3
- Create interesting traffic
- 4
- Analyze the captured traffic
1. Create access-list
In this case we create a simple access-list capturing all icmp-traffic:
ASA1(config)# access-list PING permit icmp any any
2. Create captures
To simplify we create one capture on the outside interface and one on the inside:
ASA1(config)# capture capture1 access-list PING interface inside
ASA1(config)# capture capture2 access-list PING interface outside
3. Show the captures
ASA1(config)# show capture capture1
5 packets captured
1: 00:13:37.519031 192.168.0.52 > 10.0.0.10: icmp: echo request
2: 00:13:39.490849 192.168.0.52 > 10.0.0.10: icmp: echo request
3: 00:13:41.481527 192.168.0.52 > 10.0.0.10: icmp: echo request
4: 00:13:43.494908 192.168.0.52 > 10.0.0.10: icmp: echo request
5: 00:13:45.454337 192.168.0.52 > 10.0.0.10: icmp: echo request
5 packets shown
ASA1(config)# show capture capture2
10 packets captured
1: 00:13:37.519031 10.0.0.1 > 10.0.0.10: icmp: echo request
2: 00:13:37.677745 10.0.0.10 > 10.0.0.1: icmp: echo reply
3: 00:13:39.490849 10.0.0.1 > 10.0.0.10: icmp: echo request
4: 00:13:39.554170 10.0.0.10 > 10.0.0.1: icmp: echo reply
5: 00:13:41.481527 10.0.0.1 > 10.0.0.10: icmp: echo request
6: 00:13:41.506748 10.0.0.10 > 10.0.0.1: icmp: echo reply
7: 00:13:43.494908 10.0.0.1 > 10.0.0.10: icmp: echo request
8: 00:13:43.702676 10.0.0.10 > 10.0.0.1: icmp: echo reply
9: 00:13:45.454337 10.0.0.1 > 10.0.0.10: icmp: echo request
10: 00:13:45.561143 10.0.0.10 > 10.0.0.1: icmp: echo reply
10 packets shown
4. Analyze
When we look at the captures we see clearly that we only get icmp echo requests on the inside interface but on the outside interface we see both echo requests and echo replies. Therefore we can draw the conclusion that it is the firewall that is blocking the traffic. When we review the ASA config we see that there isn’t any inspection on icmp so we add the following line to the code:
policy-map global_policy
class inspection_default
inspect icmp
then we issue a ping:
inside_host#ping 10.0.0.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/90/184 ms
Then capture on the inside interface sees all traffic:
ASA1#show capture capture1
10 packets captured
1: 00:23:48.789906 192.168.0.52 > 10.0.0.10: icmp: echo request
2: 00:23:48.835650 10.0.0.10 > 192.168.0.52: icmp: echo reply
3: 00:23:48.911085 192.168.0.52 > 10.0.0.10: icmp: echo request
4: 00:23:48.939847 10.0.0.10 > 192.168.0.52: icmp: echo reply
5: 00:23:48.950497 192.168.0.52 > 10.0.0.10: icmp: echo request
6: 00:23:48.978861 10.0.0.10 > 192.168.0.52: icmp: echo reply
7: 00:23:49.049268 192.168.0.52 > 10.0.0.10: icmp: echo request
8: 00:23:49.049268 10.0.0.10 > 192.168.0.52: icmp: echo reply
9: 00:23:49.059201 192.168.0.52 > 10.0.0.10: icmp: echo request
10: 00:23:49.070369 10.0.0.10 > 192.168.0.52: icmp: echo reply
10 packets shown
Analyzing the traffic in wireshark
This was a simple example with very little traffic going through the ASA. When you do captures on live systems you will see a lot more traffic (it depends of course on the narrowness of the ACL) then it would be great to take the capture to Wireshark for analysis.
One prerequisite is that you have ASDM installed and configured and after a capture you surf to https://ASA_IP/admin/captu
I hope this has given you new ideas how to work when troubleshooting your firewall traffic, thank you for reading and good luck!