Welcome to WordPress. This is your first post. Edit or delete it, then start writing!
We understand that a lot of our customers and users have issues troubleshooting Site-to-Site VPN tunnels.
Here’s a small reference sheet that you could use while trying to sort such issues.
Firstly, the two most important commands when troubleshooting any vpn tunnel on a cisco device:
1. “show crypto isakmp sa” or “sh cry isa sa”
2. “show crypto ipsec sa” or “sh cry ips sa”
The first command will show the state of the tunnel. For an tunnel to be perfectly up and passing traffic like it is supposed to, you should see a status “MM_ACTIVE” on an ASA and “QM_IDLE” on a router. The second command will show you the tunnel stats in detail showing clearly the number of packets encapsulated and decapsulated through the vpn tunnel. These numbers should be more or less equal.
(Henceforth throughout the document, I shall be referring to the above mentioned commands as command 1 and command 2 respectively)
Tips to Remember
1. Upon issuing command 1, if you see the status as “MM_NO_STATE” on an ASA or “MM_WAIT_MSG2” on a router, then you would want to –
a. Check the ISAKMP policies that are configured on both the ends of the tunnel to check if the parameters are matched. By ISAKMP policies, I am referring to the parameters that have been configured after issuing the command “crypto isakmp policy <policy-number>” within the sub-prompt. Out of the multiple policies that may have been configured at both ends, at least one policy must match completely with the peer policy, else you would see this status message. Make sure that you match the parameter “group” as well else you will still see this status message.
b. Check if you are able to ping the peer IP address. Also check with your ISP providers on both ends to see if they have blocked UDP port 500 at their end. Blocking of port 500 can also result in this status message.
2. Upon issuing command 1, if you see the status as “MM_WAIT_MSG4” on a router, you would want to check the value of the “group” parameter set under the “crypto isakmp policy <policy-number>” for the policy that is supposed to match on both ends of the tunnel. This parameter has to match on both ends, just like all the other parameters.
3. Upon issuing command 1, if you see the status as “MM_KEY_EXCH” on an ASA or “MM_WAIT_MSG6” on a router, then you would want to ensure that the pre-shared-key you are using on both ends is exactly matched, character by character.
4. Upon issuing command 1, if you see the status “MM_ACTIVE” on an ASA or “QM_IDLE” on a router, issue command 2. If for some reason the traffic is not passing through the vpn tunnel successfully, then you might want to check the IPSEC transform set that has been set under the crypto map for both ends. Here too, the parameters must match at all times.
5. Upon checking to see if traffic is passing successfully, if you find that traffic is not successfully passing through the tunnel, you would also need to check if the traffic for that vpn tunnel has been either exempted from the NAT process by using the “nat (interface-name) 0” command or if the crypto acl has the natted IP of the subnet and not the real IP.
1. Always enable ISAKMP on the interface that you want to terminate the VPN tunnel on. You can do this by issuing the command “crypto isakmp enable <interface-name>”.
2. Always apply the crypto map to the same interface that has the isakmp enabled. The command “crypto map <map-name> interface <interface-name>” should do the trick!
3. Ensure that there is only one crypto map applied to a particular interface.
4. Ensure that the crypto acl’s or access-list that are used to match traffic to go through the vpn tunnel do not overlap with other access-lists applied to tunnels going to other peers.
This can cause a major traffic passage issue although the status of the tunnel will show as “MM_ACTIVE” or “QM_IDLE”. Hope this helps!