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
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
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.