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 86400crypto ikev1 policy 20
authentication pre-share
encryption aes-256
hash sha
group 5
lifetime 86400crypto 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.