Capturing VPN Traffic

mattrgee

Hi,

We have a site to site VPN with a third party and capture traffic as it leaves our inside interface to help diagnose faults. Is it possible to capture this traffic before it leaves the inside interface to help verify that the ASA isn't filtering traffic? We could then see traffic arrive in the ASA and verify that it has left.

Thanks!

peanutnoggin

Have you tried setting up a SPAN port? That should duplicate the traffic and allow you to send that to a designated port where you can capture the data!

Paul Boz

I can think of a couple of ways that you can do this. One would be to add a span port to monitor all traffic leaving the internal segment. This may be a problem though because recording full-content data is extremely resource hungry (lots of disk space). You may want to look at the input and output statistics for the ASA. You should be able to correlate the number of incoming and outgoing traffic streams.

You can also set up logging on the ASA to notify you if any drops or filter actions.

Is there any reason why you suspect traffic is being dropped?

Ahriakin

You can capture inside the ASA itself, it's very flexible. The simplest is to define an ACL with the traffic you want to grab, or if you specify 'type asp-drop' you'll see whole load of suboptions to capture traffic that is dropped for various reasons.

e.g.
access-list MYCAPTURE-ACL permit ip 10.10.10.0 255.255.255.0 20.20.20.0 255.255.255.0

capture MYCAPTURE access-list MYCAPTURE buffer xxxxxxx int xxxxxxxxx

You can apply the same capture to multiple interfaces, either change the name aswell as the int for separate captures or issue the same statement with a dif. int name (it will append it to the existing and not replace the initial int, this is very handy on trunks where you can see if you have 2 of each packet with the ingress and egress vlans tagged).

You can view basic details with sh capture (name), or download the pcap with https://(ASA IP)/capture/(CAPTURE NAME)/pcap

It used to be quite transparent but 8.2 upwards the process seems to use more CPU time so watch that while you work - there is also a bug in 8.2.1 that can cause interfaces to start dropping packets at random when you pass a certain threshold with a capture in place (in our case it was passing 400kpps on a 5580).