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!