Hi All,
I wanted to share something that I've found useful during troubleshooting.
[Sorry for the wall of text in advance]
I have on open TAC case where we see some issues with the Firepower Control/Application features.
Basically, we have an ACP rule where we want to block any application that matches the "peer to peer" category. Simple really. When the traffic is being evaluated, all rules below this P2P-Block rule will get skipped (since the action is set to Block on this rule, it is quite high in my policy to conserve some CPU cycles) and the device will use the default action to evaluate the connection.
Anyway, we have been asked by TAC to capture control-plane and data-plane traffic. When you look at the capture later, you can see an Ethernet II frame. In this Ethernet frame you will normally see communication between MAC addresses 00:00:00:00:01:00:02 and 00:00:00:02:00:02. I assume the MAC 01 belongs to the ASA and the 02 to the module (in my case, it's the Firepower module). The protocol field is set to 0xfffd, which is not too useful.
I wanted to dig deeper as I suspected that the real packets are in there somewhere :) Unfortunately, Google is not your friend on how to strip the outer encapsulation on these packets. I have found the following: https://github.com/SillaRizzoli/asa_dataplane_protocol/blob/master/README.TXT and https://supportforums.cisco.com/discussion/13137731/gre-traffic-fp-module-wireshark-decoder-dataplane-traffic however I could not use the LUA either, so I started to play around with my capture file.
Long story short...
After taking off the outside header, I've found a custom protocol that I guess is Cisco-proprietary. After stripping this and some padding I managed to find the original packets being redirected to the sensor.
So, if you suspect you suffer from packet loss between the ASA and the SFR module, you can do an end-to-end capture on the ASA as follows:
ASA capture setup
|
! Packet capture on the inside interface
capture input_capture interface <input_interface> match <ip|tcp|udp|etc.> host <source IP> host <destination IP>
! Packet capture on the outside interface (capture happens before NAT, so please ensure that you have the correct addresses set below
capture output_capture interface <output_interface> match <ip|tcp|udp|etc.> host <source IP> host <destination IP>
! Packet capture on the dataplane - assign a bigger buffer as the default can get flooded quickly
capture dataplane_capture interface asa_dataplane buffer 1024000
|
Copy the capture to flash/remote storage
Run the test (should you need to), then save the PCAP files. I usually create a local copy on flash, then reach out from my linux server and fetch it through SCP. I will show you the SCP transfer too.
|
! Repeat for all three capture files
copy /pcap capture: disk0:
! Stop the captures
no capture input_capture
no capture output_capture
no capture dataplane_capture
! enable the SCP feature
conf t
ssh scopy enable
!
end
write mem
|
Once this is done, just reach out to the firewall from a server (in my case it's a Linux server - I have left the verbose switch on the commands so I can see if something breaks):
|
scp -v user@fw_ipaddress:disk0:input_capture input_capture.pcap
scp -v user@fw_ipaddress:disk0:output_capture output_capture.pcap
scp -v user@fw_ipaddress:disk0:dataplane_capture dataplane_capture.pcap
|
OK, so now you have two fully readable PCAP files, and a PCAP file from the dataplane. The outer encapsulation is 66 bytes long, so let's chop this much from the capture:
| editcap -C 66 dataplane_capture.pcap dataplane_noheader.pcap |
Editcap comes with any wireshark installation.
So here you go, hopefully I have saved some time for you. Now you should have three fully readable PCAP files, containing each stage of your packet flow, and you should be able to troubleshoot further.
PS: this is the first discussion I've posted and I wanted to start with something small, so sorry if it is not too detailed or not too helpful.
