Debugging IKEv1 on ASA

In the post I want to cover understanding IKEv1 status messages & debugging IKEv1 main mode. It is important as each message has its own unique meaning, and these messages are typically seen when attempting to establish a VPN. The lab/blog that will be referenced in the debugs is this one: Configuring & Verifying ASA Legacy IKEv1 L2L VPN - CLI

To establish phase 1 of an IKEv1 VPN using main mode, 6 messages are exchanged between the two identified peers before a successful security association is established.

Breaking down ASA Phase 1 Debugs:

Note: all traffic is initiated from the CSR behind ASA3 in the topology from the post shared above. The following debugs are generated from the initiator for this phase 1 debug breakdown:

Main Mode - MM1: Initial proposals for IKE & initiator constructing SA payload to send to responder

Main Mode - MM2: Initiator receives packet from responder deeming proposals are acceptable

Main Mode - MM3: NAT discovery & part 1 of DH exchange

Main Mode - MM4: Includes NAT payload & DH exchange continuation

Main Mode - MM5: Now initiator (ASA3 in this case) sends its identity. You can also see that we now land on the respective tunnel group. Local identity & key is sent to responder (peer)

Main Mode - MM6: Responder sends identity back to initiator & phase 1 completes:

After phase1 completes the IKEv1 state will depict MM_ACTIVE. This can be seen via the following:

#show crypto ikev1 sa
#show crypto isakmp sa

The following is a breakdown of the different types of states you may encounter should there be an issue:

NOTE: Issues from the initiator side include the following states MM_WAIT_MSG2/MSG4/MSG6

  • MM_WAIT_MSG2 (Initiator): this state occurs when the initiating peer sends message one. In this initial message it sends its IKE policy containing its configured HAGLE parameters for security association negotiation. The initiator will wait at MM_WAIT_MSG2 until it hears back from the responder. If the initiator is hung here it typically means the remote peer is not responding. You can view the state via #show crypto ikev1 sa

  • I shut the connecting interface down on the responder side & we can see the IKEv1 State is MM_WAIT_MSG2:

  • MM_WAIT_MSG4 (Initiator): At this point in the message exchange the peers have agreed on IKE policy to being establishing the security association. Now the initiator sends its authentication mechanism. The initiator will sit at MM_WAIT_MSG4 until it gets authentication back from the responder. Typically if a device is hung in this state it could mean the tunnel group is missing.

  • Purposely removed tunnel-group from responder config:

  • MM_WAIT_MSG6 (Initiator): Checks to ensure PSKs match, if they do the message state on the initiator will move to MM_ACTIVE and lets the responder know that they match. If there is a PSK mismatch, then the initiator will sit at MM_WAIT_MSG6.

  • Purposely misconfiguring PSK on the responder:

The following are breakdowns of the message states from the responder perspective:

Responder states include: MM_WAIT_MSG3/MSG5

  • MM_WAIT_MSG3 (Responder): Remote peer sends back its IKE policy to the initiator. Connectivity issues, device mismatches, or a firewall may cause this.

  • MM_WAIT_MSG5 (Responder): Remote peer sends its PSK hash to the initiator. The responder typically is in this state if there is a PSK issue.

  • Purposely misconfigured the PSK on responder side:

Additional debug depicting IKE policy mismatch:

That wraps this blog up. Hopefully you have a better understanding of IKEv1 messages/states & debugs. Cheers!


Recent Posts

See All

"The What?" - In this post I will cover configuring & verifying a basic site-to-site VPN tunnel between two Cisco ASAs using IKEv1 with pre-shared keys (PSK). These types of VPNs are also known as L2

In this post I want to cover the components & general understanding of how the ASA AnyConnect (AC) Webdeploy process works. First, it is important to understand that the AnyConnect client on an end no