Troubleshoot VPN was never easy

Does not matter Cisco router or ASA, the troubleshooting process for Site2Site VPN was never a piece of cake. In order to get Tunnel up and running, phase 1 – IKE has to successful. Fortunately, Cisco does not vary the troubleshooting command a lot from IOS to ASA for showing IKE negotiation status.

show crypto isakmp sa

Depends on the output from command above, trouble shoot can go different directions:

Here are some message examples that might show up on ASA:

MM_WAIT_MSG2

Initial DH public key sent to responder. Awaiting initial contact reply from other side.

If stuck here it usually means the other end is not responding. This could be due to no route to the far end or the far end does not have ISAKMP enabled on the outside or the far end is down.

MM_WAIT_MSG3

Both peers have agreed on the ISAKMP policies. Awaiting exchange of keyring information.

Hang up’s here may be due to mismatch device vendors, a router with a firewall in the way, or even ASA version mismatches.

MM_WAIT_MSG4

In this step the pre-share key hashes are exchanged. They are not compared or checked, only sent. If one side sends a key and does not receive a key back, this is where the tunnel will fail.

I have seen the tunnel fail at this step due to the remote side having the wrong Peer IP address. Hang up’s here may also be due to mismatch device vendors, a router with a firewall in the way, or even ASA version mismatches.

MM_WAIT_MSG5

This step is where the devices exchange pre-shared keys.

If the pre-shared keys do not match it will stay at this MSG. I have also seen the tunnel stop here when NAT Traversal was on when it needed to be turned off.

MM_WAIT_MSG6

This step is where the devices exchange pre-shared keys. If the pre-shared keys do not match it will stay at this MSG. Sometime, if NAT Traversal was on when it needed to be turned off, the process could also stuck in this step.

However, if the state goes to MSG6 then the ISAKMP gets reset that means phase 1 finished but phase 2 failed. Check that IPSEC settings match in phase 2 to get the tunnel to MM_ACTIVE.

AM_ACTIVE / MM_ACTIVE. The ISAKMP negotiations are complete. Phase 1 has successfully completed.

Here are also some common items to check if phase 1 not establishing correctly.
1.Verify ISAKMP parameters match exactly.
2.Verify pre-shared-keys match exactly.
3.Check that each side has a route to the peer address that you are trying to form a tunnel with.
4.Check the protected subnet(s) for tunnel.
5.Verify ISAKMP is enabled on the outside interfaces.
6.Is ESP traffic permitted in through the outside interface?
7.Is UDP port 500 open on the outside ACL?
8.Some situations require that UDP port 4500 is open for the outside.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s