Your Troubleshooting Workflow for Proving ASA Site-to-Site VPN Connectivity on Your Side of the Tunnel is Not Down

[Alan Inman]

I'm an accidental administrator of an ASA 5555. The biggest five-alarm fires I get are "The tunnel is down! The vendor can't connect!" Then I have to prove the issue is not on our side of the tunnel. I never feel like I approach this the same way, and I never feel like I approach it efficiently. 

Will you share your troubleshooting steps (CLI/GUI) for immediately determining the issue is not on your side of the tunnel? I'm trying to put together a solid playbook I can refer to when faced with tunnel issues. 

Thank you very much for your time, 

-Alan

[Rob Ingram · Accepted solution]

Hi,

When you are troubleshooting you should:-

- Check the IKE SA "show crypto isakmp sa" or "show crypto ikev1 sa" or "show crypto ikev2" - determine if established

- Check the IPSec SA "show crypto ipsec sa" - determine if IPSec SA is established, determine if encaps|decaps are increasing.

- Turn on debugs "debug crypto ikev1" or "debug crypto ikev2" -observe the output

- Generate interesting traffic as defined in the ACL referenced in the crypto map, see if the tunnel comes up

- Run packet-tracer e.g "packet-tracer input inside tcp 192.168.100.3 3000 10.10.0.2 80"

- Check NAT exemption rules are in place and traffic is not unintentially natted

- Take a packet capture on outside interface and confirm inbound udp/500, esp or udp/4500 is received from peer

The following links are useful for troubleshooting ASA VPN.

https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/81824-common-ipsec-trouble.html

https://community.cisco.com/t5/security-documents/asa-how-to-troubleshoot-vpn-l2l-ensure-traffic-is-passing/ta-p/3166082

HTH

[Alan Inman]

Thank you! I greatly appreciate you taking the time to share this information.