Capturing specific traffic on ASA

By | January 7, 2019

Capturing traffic on ASA firewall with CAPTURE command is easy but capturing specific traffic between two host play’s an important role during production hours and if we have too many host on the network. Lets practice one such case.

Study Case : PC [ 10.1.1.1 ] shown above diagram is able to communicate with the server1- 64.1.1.2 but not with Server2 – 64.1.1.3. Ping from PC1 to server 64.1.1.3 fails. Configuration looks correct on ASA for both outside and inside interface.We also dont have access to any device outside interface of ASA to check their end configuration.

PC#ping 64.1.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 64.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/24/32 ms

PC#ping 64.1.1.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 64.1.1.3, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)

PC#sho arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.1.1.1 – c202.071e.0000 ARPA FastEthernet0/0
Internet 10.1.1.50 2 0c9f.4449.6703 ARPA FastEthernet0/0
PC#

Once the above step is done, the next thing you do here to check the connectivity between server2 and ASA outside interface. We can see below layer 3 pings fails and also we can see we dont have arp entry in the ARP table of ASA for 64.1.1.3

ASAv# ping 64.1.1.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 64.1.1.3, timeout is 2 seconds:
?????
Success rate is 0 percent (0/5)
ASAv#

ASAv# sho arp
outside 64.1.1.2 c201.070d.0000 17
man 1.1.1.2 c203.09b2.0000 107
ASAv# sho arp | in 64.1.1.3
ASAv#

The ARP table shown on ASA [ version 9.9 ]above is little bit confusing as we are not quickly sure whether ( On cisco IOS router you will at-least see incomplete which tells we have tried sending ARP request but it is incomplete) ASA outside interface sent any ARP request packet to the server 2 or not. We cannot just run debug command in production to check this and it is also not efficient way to capture all ARP traffic in and out so lets see now how can we filter specific traffic. i am going to capture arp request and arp reply from ASA outside interface [ 64.1.1.50 ] to 64.1.1.3. The syntax is below.

ARP Request

capture < filename > interface < your connected interface > ethernet-type < protocol : arp here > match mac< source_mask> any

in our case :

capture arp1req interface outside ethernet-type arp match mac 0c9f.4449.6702 ffff.ffff.ffff any

FFFF is a hex value to match the exact address.just like 255 in the IP subnet mask address field in the Layer 3 address. This value plays an important role to capture specific layer 2 traffic with the mac address.

ARP reply

capture < filename > interface < your connected interface > ethernet-type < protocol : arp here > match mac< source_wild_card_mask> < destination_wild_card_mask>

In our case :

capture arp1rep interface outside ethernet-type arp match mac c204.084c.0000 ffff.ffff.ffff 0c9f.4449.6702 ffff.ffff.ffff

After executing the above commands now, we can see below now that we are sending ARP request but we are not getting any reply. This tells us that we have issue on other side of outside interface of ASA. We can also can see below, we are just filtering the specific traffic with respect to ARP to specific host 64.1.1.3 only, not all.

ASAv#sho capture arp1req

5 packets captured

1: 13:56:48.604827 arp who-has 64.1.1.3 tell 64.1.1.50
2: 13:56:49.703866 arp who-has 64.1.1.3 tell 64.1.1.50
3: 13:56:50.701089 arp who-has 64.1.1.3 tell 64.1.1.50
4: 13:56:54.701303 arp who-has 64.1.1.3 tell 64.1.1.50
5: 13:56:59.709008 arp who-has 64.1.1.3 tell 64.1.1.50
5 packets shown

ASAv#sho capture arp1rep

0 packet captured

0 packet shown

There are other way to detect this issue [ shown below] but sometime looking at directly packets will help in understanding what our device is doing and this intern help in faster resolution of the problem. I hope this help.

ASAv# sho arp statistics
Number of ARP entries in ASA: 2

Dropped blocks in ARP: 4
Maximum Queued blocks: 2
Queued blocks: 1
Interface collision ARPs Received: 0
ARP-defense Gratuitous ARPS sent: 0
Total ARP retries: 4
Unresolved hosts: 1
Maximum Unresolved hosts: 1
ASAv#

2 thoughts on “Capturing specific traffic on ASA

Leave a Reply

Your email address will not be published. Required fields are marked *