Cisco VPN Phase 1 issue with NO_PROPOSAL_CHOSEN and MM_WAIT_MSG2

When establishing VPN tunnel for the first time and having troubles bringing it up you may need to enable debugging as well as checking its state on your appliance. 

With debugging enabled on phase 1 you might be able to see the following notification message:

!enable debug for phase 1. Note #177 which gives you “enough” log

debug crypto ikev1 177

!snippet from debug showing NO_PROPOSAL_CHOSEN notification

Nov 02 14:33:24 [IKEv1]IP = 172.68.245.46, Received an un-encrypted NO_PROPOSAL_CHOSEN notify message, dropping

Nov 02 14:33:24 [IKEv1]IP = 172.68.245.46, Information Exchange processing failed

Additionally, your can verify VPN state to get more info where it got stuck.

!verifying ikev1 current state

sh crypto ikev1 sa

IKE Peer: 172.68.245.46
Type : L2L Role : initiator
Rekey : no State : MM_WAIT_MSG2

By the definition MM_WAIT_MSG2 initiator initials DH public key send to responder and awaits initial contact reply from the other side. Initiator sends encr/hash/dh ike policy details to create initial contact. If it gets stuck at this point it typically means the other side couldn’t properly respond to our request. In most cases there are some issues with the other side(if you are initiator). If you are a responder reverse the logic.

MM_WAIT_MSG2 stuck could be due to routing issue, ISAKMP(Internet Security Association and Key Management Protocol) not enabled on the other side or It could also mean that ISAKMP might have a mismatch.

!verifying routing

sh run route

route outside 172.68.245.46 255.255.255.255 nextHopIP

!verifying  if ISAKMP is enabled

sh run crypto ikev1

crypto ikev1 enable outside

It this particular scenario there was no routing issues and ISAKMP was enabled on the outside so at this point you need to start with basics.

That being said with NO_PROPOSAL_CHOSEN it might mean we have a mismatch somewhere on phase 1 of our VPN tunnel. 

Verifying your policy proposals for IKEv1 and matching it with your peer is your next step.

!verifying IKEv1 crypto policies

sh run crypto ikev1 | b policy

crypto ikev1 policy 10
authentication pre-share
encryption aes-256
hash sha
group 2
lifetime 86400

crypto ikev1 policy 20
authentication pre-share
encryption aes-256
hash sha
group 5
lifetime 86400

crypto ikev1 policy 30
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400

As shown above in this particular enrollment we have (3) ikev1 policies: 10,20,30. ASA will perform top down approach to find the match between both end points. If none of them matches you may get an error message mentioned above.

This is the time where both parties should be on the call verifying if any of the (3) ISAKMP’s are a match. It is a good time to also double check your interesting traffic to eliminate any phase 2 issues. 

In my scenario this was exactly what happened.  Even after exchanging VPN form with proposals the other end never configured their side which caused the problem initiating the tunnel. Adding the proper ikev1 policy(authentication,ecryption,hash,group,lifetime) to the list will fix the problem.

I hope this has been informative to you and thanks for stopping by. Please drop a comment if you still having problems and i’ll be more than happy to assist.

Regards,
Bart

Resource:

If you are interested in different states for phase 1 I would strongly recommend visiting tunnelsup.com kb. No purpose of reinventing the wheel here.