Validating a Cisco ASA VPN is Passing Traffic or Find Out Which Side is Having Issues

I spend a good deal of time troubleshoot Cisco ASA site to site VPNs, sometimes with access to both sides, but mostly with access to only one side.  So many times the issue is where the VPN tunnel is up, but you still cannot get a round trip ping to complete or in other words you do not have two way traffic.

Since our case is where the tunnel is up, and we are not passing traffic, this typically means one or both sides has a route or a NAT issue.  The question is which side.  First the I run the command: “show crypto isakmp sa”.  This will give me a list of all the VPN tunnels and their peer IP address.

pei-hq-vpn01# show crypto isakmp sa

IKEv1 SAs:

Active SA: 14

Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)

Total IKE SA: 14

1   IKE Peer: 216.99.99.99

Type    : L2L             Role    : responder

Rekey   : no              State   : MM_ACTIVE

…

9   IKE Peer: 204.86.99.11

    Type    : L2L             Role    : initiator

    Rekey   : no              State   : MM_ACTIVE

This show that that the tunnel is Active, but we cannot tell if traffic is passing and from what direction.  To solve these issue I run the command: “show crypto ipsec sa peer <Peer IP address>”

pei-hq-vpn01# show crypto ipsec sa peer 204.86.99.11

peer address: 204.86.119.11

Crypto map tag: outside, seq num: 230, local addr: 198.17.138.2

access-list PEI-2-XXX-COLO extended permit ip 10.99.0.0 255.255.0.0 10.98.1.0 255.255.255.0

local ident (addr/mask/prot/port): (10.222.0.0/255.255.0.0/0/0)

remote ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0)

current_peer: 204.86.119.11

#pkts encaps: 4176, #pkts encrypt: 4176, #pkts digest: 4176

      #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 4176, #pkts comp failed: 0, #pkts decomp failed: 0

#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0

#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0

#TFC rcvd: 0, #TFC sent: 0

#Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0

#send errors: 0, #recv errors: 0

The main lines that we are looking at are the “packets encaps” and “packets decaps”.   The packets encapsulated are the packets you are pushing into the VPN.  If this is zero, you have an issue on the local firewall side of the VPN.  If this has a number, but the packets decapsulated is zero, it means the remote side has an issue.

Since the tunnel is built we are not looking at any of the standard parameters of the crypto, but we can focus to just the NAT and the routes.  The first thing to validate is that the route for the remote network is correct and pointing to the crypto map interface (typically the outside interface).  Secondly, check the NAT statements.  Ensure that the NAT (or noNAT) statement is not being masked by any other NAT statement.  Typically in troubleshooting I raise the suspected NAT statement to the top of the list.

NAT statement will supersede routes unless the statement has route-lookup on them.  So make sure the NAT statement has the correct interfaces and isn’t pushing the traffic out the incorrect interface.

Jason Howe, PEI