Hi guys,
I recently had to build a new tunnel and then debug. I dug forums for couple hours and could not find any head to tail thread about this. I will just cite from other threads and try to merge into a more complete one.
There are two steps for debugging (the old way, via SSH).
1. Enable debug
2. Read the logs. There it was my main challenge.
Step 1: enable debug
Depending on the software version running, I will just quote from this thread:
The 1st two go-to commands are:
show crypto isakmp sa
show crypto ipsec sa
If Phase 1 and Phase 2 aren't up per those respective commands, then go to:
debug crypto isakmp 7
debug crypto ipsec 7
You may need to increase the verbosity level (255 is the highest) and, if you have multiple SAs, focus on the one you are interested in with a filter:
debug crypto condition peer <peer IP>
Once you have Phase 1 and 2 established but are having continued problems with bidirectional traffic flow, look at two things:
1. In the show crypto ipsec sa output, do decaps increase commensurate with the encaps. If not, the distant end may not be getting the return traffic. Confirm with a packet capture and/or trace.
2. Use the packet-tracer command (CLI or GUI) on the ASA to examine how it will treat a given flow. NAT and ACL issues can often be quickly seen using that tool.
Step 2: read the debug
As you know Cisco ASA is a very log_noisy appliance. If you are not careful a VPN debug session can easily turn into a firewall_down session.
When debugging I usually go for "terminal monitor" and read the output. Don't try this on ASA!
I was surprised to find out that most of the ASA engineers don't rely on the old router VPN debug because of this. Here's a very good debug thread, but the reading the logs part.
Here's my idea:
logging list DEBUG_VPN level debugging class vpn
logging monitor DEBUG_VPN
terminal monitor (only after properly configuring logging monitor).
Obviously I would be glad to know your thoughts about this and of course improve this method.
