Der Fehler IKE protocol notification message received: NO-PROPOSAL-CHOSEN (14) zeigte nicht wie zuerst gedacht an, dass ein Proposal „nicht ausgewählt wurde“ sondern, dass im konkreten Fall NOPFS nicht gesetzt wurde.
Problem or Goal:
Environment:
- IKE Phase 1 negotiation successful
- Phase 2 initiated negotiation before the ’no proposal chosen‘ message appeared
IKE protocol notification message received: NO-PROPOSAL-CHOSEN (14)
Symptoms & Errors:
- IKE Phase 2 negotiation fails
- Initiator received notify message for DOI <1> <14> <NO_PROPOSAL_CHOSEN>
- Message similar to these reported in logs:
- Jan 25 20:28:36 [IKED 2] IKE negotiation fail for local:192.168.1.80, remote:192.168.3.40 IKEv2 with status: No proposal chosen
- May 21 18:11:50 ike_st_i_n: Start, doi = 1, protocol = 1, code = No proposal chosen
Cause:
Solution:
If phase 2 negotiation has been initiated, and you get the „Error = NO_PROPOSAL_CHOSEN“ message, this indicates a mismatch in proposals between the two peers. The phase 2 proposal elements include the following:
- Authentication algorithm (MD5, SHA1)
- Encryption algorithm (DES, 3DES, AES128, AES192, AES256)
- Lifetime kilobytes (sometimes referred to as lifesize)
- Lifetime seconds
- Protocol (AH, ESP)
- Perfect Forward Secrecy (Diffie-Hellman group1, group2, group5)
If phase 2 fails to complete with an error in proposal, then confirm that remote peer has at least one proposal configured in which Authentication and Encryption algorithms, Protocol and Perfect Forward Secrecy (PFS) match at least one proposal on the local side. A common mis-configuration is PFS group key mismatch. Perhaps one side has PFS group key configured whereas the remote side may either not have PFS enabled or incorrect group key. Also, with some third-party non-Juniper devices, Lifetime in both kilobytes and/or seconds may also need to match.