ISAKMP (IKE Phase 1) Status Messages MM_WAIT_MSG

To establish Phase 1 of a IKE VPN, 6 messages need to be sent between the 2 peers before it can complete. Sometimes when you try to establish a VPN, you will see that the VPN gets stuck at one of these MM_WAIT_MSGs. I will break down each message below and what it may signify if the VPN is stuck at one of these messages.

You can see the status of Phase by looking at the 'show isakmp sa' output. If you have several tunnels then you may want to start the output at your Peer IP 'show isakmp sa | begin X.X.X.X' where X.X.X.X is the Peer IP you are trying to troubleshoot.

 

ASA-LAB1# show isakmp sa                                                 

IKEv1 SAs:

   Active SA: 1
    Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1

1   IKE Peer: 50.56.229.98
    Type    : L2L             Role    : initiator 
    Rekey   : no              State   : MM_ACTIVE

 

ASA-LAB1# show isakmp sa | begin 50.56.229.98
1   IKE Peer: 50.56.229.98
    Type    : L2L             Role    : initiator 
    Rekey   : no              State   : MM_ACTIVE

MM_WAIT_MSG2 (Initiator)

The initiating peer will send message one and will be in a MM_WAIT_MSG2 state. In the initial message, it is sending its Encryption, Hash, DH Group and Lifetime Policy details to the Remote Peer. If you see that you are stuck at this message then this means that the other side is not responding to your requests. This could be that Remote Peer is blocking UDP port 500, they are not configured to listen for IKE traffic or you are not able to reach the peer due to routing issues.

Checking with the Remote side to see if they are getting your message 1 is a good first step. If they state they see MM_WAIT_MSG3, then refer to MM_WAIT_MSG3 below.

ASA-LAB1#   show isakmp sa

IKEv1 SAs:

   Active SA: 1
    Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1

1   IKE Peer: 50.56.229.98
    Type    : user            Role    : initiator 
    Rekey   : no              State   : MM_WAIT_MSG2

MM_WAIT_MSG3 (Responder)

The Responding peer has responded with message two and will be stuck in a MM_WAIT_MSG3 state. This should rarely happen because if Message 2 was sent back to the peer, then the initiating peer should be able to respond with Message 3. This can happen for a few reasons but the most common is ISP issues. This can be the route back to the initiating peer or UDP 500 could be blocked from the Responding Peer to the Initiating Peer on their edge. Have the Peer with this message check that UDP 500 is allowed from their environment and that they are not having any routing issues back to the Initiating peer.

ASA-LAB2(config)# show isakmp sa

IKEv1 SAs:

   Active SA: 1
    Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1

1   IKE Peer: 50.57.228.150
    Type    : user            Role    : responder 
    Rekey   : no              State   : MM_WAIT_MSG3

MM_WAIT_MSG4 (Initiator)

At this point, the Initiating and Responding Peers have agreed on the IKE Policy (Encryption, Hash, DH Group) and are beginning the process of checking if they trust the Peers IP address. The initiator here has sent Message 3 which will begin the process of trusting eachothers peer IPs. There is more that goes on here but all you really need to know is that the tunnel-groups need to exist for this phase to complete. If the VPN is at this message, then the other side most likely does not have the Initiators IP configured as a tunnel-group and is dropping the request. The best thing to do here is confirm that the Remote Peer has the right Peer IP configured in the tunnel-group settings.

ASA-LAB1# show isakmp sa

IKEv1 SAs:

   Active SA: 1
    Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1

1   IKE Peer: 50.56.229.98
    Type    : user            Role    : initiator 
    Rekey   : no              State   : MM_WAIT_MSG4

MM_WAIT_MSG5 (Responder)

At this phase, Message 4 was sent back to the Initiator and the Responder is waiting for Message 5. This means that the Ike Policies match and both Sides have their Peer IPs set correctly as tunnel-groups. If this message is present then the Pre-shared keys between the 2 peers do not match or that the Initiator does not have a pre-shared key defined at all. All settings are valid except for Pre-shared keys at this point. You will want to validate that the keys match between both peers and possibly look at special characters or spaces as these can be problematic for some termination devices.

ASA-LAB2# show isakmp sa

IKEv1 SAs:

   Active SA: 1
    Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1

1   IKE Peer: 50.57.228.150
    Type    : L2L             Role    : responder 
    Rekey   : no              State   : MM_WAIT_MSG5

MM_WAIT_MSG6 (Initiator)

This message indicates that the Pre-shared keys do not match between the peers. The initiator has sent message 5 to the Remote Peer and the Remote peer was not able to validate the Pre-shared key and doesn't respond. The best thing to do here is work with the Remote side to confirm the Pre-shared keys. When validating the Pre-shared keys, look at special characters or spaces as these can be problematic for some termination devices.

ASA-LAB1# show isakmp sa

IKEv1 SAs:

   Active SA: 1
    Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1

1   IKE Peer: 50.56.229.98
    Type    : user            Role    : initiator 
    Rekey   : no              State   : MM_WAIT_MSG6

For more references for troubleshooting VPNs please check out my VPN Troubleshoot Article or my No Proposal Chosen Article.

If you would like to know more or see more articles on VPNs, please let me know. You can contact me and I will do what I can to help.


0 Comments

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Close Bitnami banner
Bitnami
Close Bitnami banner
Bitnami