NSE4 Authentication and VPN Practice Question
A FortiGate administrator is configuring IPsec VPN between two sites. The Phase 1 negotiation fails with the error 'no proposal chosen'. Which two settings must match on both VPN peers?
⚠ Common exam trap
Many candidates confuse Phase 1 and Phase 2 parameters, mistakenly thinking that mismatched Phase 2 selectors (option C) or pre-shared keys (option A) cause the 'no proposal chosen' error, when in fact it is specifically a Phase 1 proposal mismatch involving encryption and authentication algorithms.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Encryption algorithm and authentication algorithm
The 'no proposal chosen' error during IPsec Phase 1 negotiation indicates that the two VPN peers cannot agree on a common set of security parameters for the IKE (Internet Key Exchange) SA. The encryption algorithm (e.g., AES-256, 3DES) and authentication algorithm (e.g., SHA-256, MD5) are mandatory components of the Phase 1 proposal; if they do not match on both peers, the IKE negotiation fails immediately.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Pre-shared key and local ID
Why it's wrong here
In IKE Phase 1, a pre-shared key mismatch typically results in an authentication failure or an INVALID_KEY_INFORMATION notification, not an "IKE no proposal chosen" error. The local ID is a peer-identification parameter that can legitimately differ as long as the remote peer recognizes it, and it does not influence the cryptographic algorithm negotiation. The "no proposal chosen" error specifically arises when no common transform set—encryption, authentication, and DH group—is found during the SA proposal exchange, so fixing the PSK or local ID alone would not address the real problem.
- ✗
Dead peer detection interval and retry count
Why it's wrong here
Dead peer detection (DPD) is a keepalive mechanism that operates only after an IPsec SA has been established, using R-U-THERE/R-U-THERE-ACK messages to verify peer liveness. DPD parameters such as interval and retry count are not part of the IKE SA proposal; they are exchanged as separate notification messages and have no bearing on the algorithm negotiation process. The "no proposal chosen" error occurs during the initial proposal exchange, before DPD would ever be activated. Adjusting DPD settings would therefore have zero effect on this Phase 1 failure, though it might affect long-term session stability once the tunnel is actually established.
- ✗
Remote gateway IP and Phase 2 selectors
Why it's wrong here
The remote gateway IP is a peer addressing parameter; if it is incorrect, the FortiGate would see an IKE SA timeout or no response from the peer, not a proposal-chosen failure. Phase 2 selectors define the interesting traffic (local and remote subnets) and are negotiated in Quick Mode (or IKEv2 CREATE_CHILD_SA) only after Phase 1 has already succeeded. While mismatched selectors can cause Phase 2 negotiation failures, they are completely irrelevant to the Phase 1 "no proposal chosen" message. Thus, this option conflates network-level connectivity and traffic-selection issues with the actual cause—the mismatch of Phase 1 security parameters like encryption and authentication algorithms.
- ✓
Encryption algorithm and authentication algorithm
Why this is correct
The "no proposal chosen" error is FortiGate's way of reporting that the IKE Phase 1 SA proposal could not be matched with the remote peer. The proposal is constructed from the encryption algorithm (e.g., AES256-GCM, AES256-CBC), the authentication/integrity algorithm (e.g., SHA-256, SHA-1), the Diffie-Hellman group, and in some cases the pseudo-random function (PRF). If any of these parameters differ between peers, the IKE SA negotiation fails with "no proposal chosen" during the SA payload exchange. Correcting the encryption and authentication algorithms so that both peers share at least one common proposal is the direct and expected remedy for this exact error.
Quick reference
VPN Protocol Comparison
| Protocol | Port | Encryption | Authentication | Use Case |
|---|---|---|---|---|
| IKEv2 / IPsec | UDP 500 / 4500 | AES-256 | Certificates / PSK | Site-to-site & remote access |
| SSL / TLS VPN | TCP 443 | TLS 1.3 | Certificates / MFA | Clientless remote access |
| L2TP / IPsec | UDP 1701 | AES (IPsec) | PSK / Certificates | Legacy remote access |
| WireGuard | UDP 51820 | ChaCha20 | Public keys | Modern high-performance VPN |
| PPTP | TCP 1723 | MPPE (weak) | MS-CHAPv2 | Legacy — avoid in production |
PPTP is considered insecure. IKEv2/IPsec and SSL VPN are the current recommended options.
Go deeper
Related to this question
About these practice questions
This NSE4 question is part of Courseiva's 282-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This NSE4 practice question is part of Courseiva's free Fortinet certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the NSE4 exam.