Skip to main content

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

By May 3, 2016September 11th, 2020Best Practices, Blog, Cisco
cisco logo

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

2 Comments

  • Hector Carmenates says:

    Don’t know if I can ask some questions through this way.
    For example:
    How would you check the route between the two Sites is good?
    I have read we don’t have to specify any “route” command in a L2L VPN but some days ago in a Cisco article I did read it is good to specify the route to the remote site but not specifying the next hop IP address like we do in the default gateway route but specifying the Public IP Address of the Remote Site the same we specify in the crypto map…peer in other words the peer’s IP address.
    For example in your example it would be
    #route outside 10.99.1.0 255.255.255.0 204.86.119.11
    Is that correct?
    Thank you

    • Stephanie Hamrick says:

      Hi Hector, here’s a response from the post’s author!

      You mention that you read that it is good to specify the route to the remote site, but specify the remote firewall IP address. I agree that is what I read many times. In practice I have found that it is not only unnecessary, it can cause problems. We had an issue around 6 months ago where traffic would go across the VPN fine, but we could not poll the internal interface of the firewall (via SNMP). After opening a TAC case and spending many hours troubleshooting, the fix was to remove the specific route and just rely on the interesting traffic ACL to capture the traffic. So while having a specific route (was) suggested, it can cause problems. After that instance, we do not suggest adding the extra route in the configuration and just let the crypto ACL take the traffic.

      The blog you responded to was more about the NAT (or noNAT depending on the old code level) statement trapping the traffic and “routing” traffic out an interface you were not expecting.

      From my experience the order of operations for traffic is
      1) NAT
      2) Route
      3) Crypto
      So if you have a NAT statement that says
      nat (inside, backup) source static obj-SourceIPBlock obj-SourceIPBlock destination static obj-DestIPBlock obj-DestIPBlock

      but had a route for (obj-DestIPBlock, assuming obj-DestIPBlock is 192.168.0.0/16)
      route outside 192.168.0.0 255.255.0.0 204.86.119.11

      The traffic would be captured by the NAT statement and shipped out the “backup” interface and not out the “outside” interface.

      Hopefully that helps explain why we changed from adding specific routes for crypto tunnels.

      Please let me know if you have any other questions.

Leave a Reply