A site to site IPsec VPN consists of two phases; Phase 1 – IKE exchange and Phase2 – Establishing the ipsec tunnels. It is important to figure out which part of the negotiation the VPN is failing at.
However, before all that, we should check if the traffic is getting to the firewall in the first place. To do this we should turn on icmp debug on the firewall.
debug icmp trace
If you are logged in to the firewall via ssh or telnet, unlike the console you may find that you want to redirect the output of the debug to the screen. To do this enter:
Once that is done, you can now start pinging the system you want to reach at the other end. Observe the icmp packets as it reaches the firewall, it should first reach the firewall and then NATed to the global IP that was assigned in the VPN. If this is not true, check your nat and global acls and statements. You may want to use these statements to investigate your config
sh run nat sh run global sh run access-list acl-name
If the traffic is being properly natted you are safe to turn off icmp tracing as you know the traffic is reaching the firewall and being translated properly.
The next step is to verify that PHASE 1 negotiation is complete. Make sure to keep pinging the target host as it would ensure that the VPN tunnel is staying active.
sh crypto isakmp sa detail.
This will display if the sa – security association has been established. From the output you will see the status of the negotiation, if it succeeds will you see that status has become active and your sa time to live should start to decrement.
If not, turn on debugging for the phase 1:
debug crypto isakmp
Verify that there are no mismatches in the configuration as usually that should be the problem. Do a:
sh run crypto
Verify that the config does match the configuration provided to you on the other end. You may also find that the admin on the other end may have their configuration misconfigured. Try to ensure that your configuration is correct before blaming others as you don’t want to to look stupid.
If the phase 1 configuration is complete, then you can move on to troubleshooting phase 2. Much like phase 1 you want to “sh the crypto status”.
sh crypto ipsec sa detail id-number
The id number here is the crypto-map sequence id number entered for the specific tunnel. Verify that something is displayed. If nothing is displayed then there is likely a problem with the configuration of the phase 2. Check that the ipsec transforms sets are matching as this was the problem that I ran into.
Once that is all done and both phase 1 & 2 are complete then the tunnel should be up. Now, if you have read carefully, all this requires that you ensure that the tunnel is up by launching a consistent ping against a target host at the other end. However, if you realize that both phase 1 & 2 have been established but you do not see any icmp replies, this may be to do with the NATed address that was provided to the other side. What usually happens is that the other end would have an access-list that would only allow traffic from one specific NATed ip. If this is wrong, you will not get any response even if the tunnel is up. Also, make sure that the outgoing acls on the firewall is to allow icmp going out. Depending on the corporate policy one may have defined only specific IP going out.
One last tool to troubleshoot Cisco IPsec VPNs, use the ASDM! This neat GUI will tell you all the information at a glance. It is a useful too for viewing your configuration. Also, try using the packet tracer on the ASDM. It will display in detail how the packet traverses each component in the firewall and show you the likely place to look at in your settings.
That’s it for troubleshooting VPNs. These are the problems that I ran into when I set it up. I hope when I look back at this post I can remember what pains I have gone through and ensure that I follow these steps to avoid them!