All Credits for this go to Jack Rhysider and his excellent work at https://www.tunnelsup.com/ and https://darknetdiaries.com/
ISAKMP (IKE Phase 1) Negotiations States
The MM_WAIT_MSG state can be an excellent clue into why a tunnel is not forming. If your firewall is hanging at a specific state review this graph below to find where along the path the VPN is failing.ASA ISAKMP STATES
Graph source: tunnelsup.com
These are the possible ISAKMP negotiation states on an ASA firewall.
ISAKMP stands for: The Internet Security Association and Key Management
Protocol- MM_WAIT_MSG2 Initiator Initial DH public key sent to responder. Awaiting initial contact reply from other side. Initiator sends encr/hash/dh ike policy details to create initial contact. Initiator will wait at MM_WAIT_MSG2 until it hears back from its peer. 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 Receiver Receiver is sending back its IKE policy to the initiator. Initiator sends encr/hash/dh ike policy details to create initial contact. Initiator will wait at MM_WAIT_MSG2 until it hears back from its peer. Hang ups here may also be due to mismatch device vendors, a router with a firewall in the way, or even ASA version mismatches.
- MM_WAIT_MSG4 Initiator Initiator is sending the Pre-Shared-Key hash to its peer. Initiator sends a hash of its PSK. Initiator will stay at MSG4 until it gets a PSK back from its peer. If the receiver is missing a tunnel group or PSK the initiator will stay at MM_WAIT_MSG4
- MM_WAIT_MSG5 Receiver Receiver is sending its PSK hash to its peer. Receiver does not yet check if PSK hashes match. If receiver has a tunnel-group and PSK configured for this peer it will send the PSK hash to the peer. If PSKs don’t match, receiver will stay at MM_WAIT_MSG5. I have also seen the tunnel stop here when NAT-T was on when it needed to be turned off.
- MM_WAIT_MSG6 Initiator Initiator checks if PSK hashes match. If PSK keys match, Initiator becomes MM_ACTIVE and lets receiver know of match. If PSK doesn’t match, initiator stays at MM_WAIT_MSG6. I have also seen the tunnel stop here when NAT-T was on when it needed to be turned off. 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 stay at MM_ACTIVE.
- AM_ACTIVE / MM_ACTIVE The ISAKMP negotiations are complete. Phase 1 has successfully completed.
PIX ISAKMP STATES
- MM_NO_STATE
- MM_SA_SETUP
- MM_KEY_EXCH
- MM_KEY_AUTH
- AG_NO_STATE
- AG_INIT_EXCH
- AG_AUTH
- QM_IDLE
What is the difference between MM and AM?
Main mode vs Aggressive mode. Here is a image taken from Cisco’s website to show the difference.
As you can see the Main mode is the same as the flowchart at the top of the page. Aggressive mode only uses 4 steps to establish the tunnel.
Troubleshooting ISAKMP Or Phase 1 VPN connections
When troubleshooting VPNs, a very common problem is phase 1 not establishing correctly. Here’s a quick checksheet to make sure you have the configuration correct.- Verify ISAKMP parameters match exactly.
- Verify pre-shared-keys match exactly.
- Check that each side has a route to the peer address that you are trying to form a tunnel with.
- Verify ISAKMP is enabled on the outside interfaces.
- Is ESP traffic permitted in through the outside interface?
- Is UDP port 500 open on the outside ACL?
- Some situations require that UDP port 4500 is open for the outside.
