NSE4 Authentication and VPN Practice Question
A network administrator configured an IPsec VPN between two FortiGates. Phase 1 is up, but Phase 2 fails to establish. The diagnose output shows 'no matching proposal'. What is the MOST likely cause?
⚠ Common exam trap
Many candidates confuse Phase 1 and Phase 2 failures, assuming any 'no matching proposal' error relates to authentication or peer reachability, when it specifically points to mismatched IPsec SA parameters like encryption or 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
✓
The Phase 2 encryption and authentication algorithms do not match between peers
The 'no matching proposal' error in Phase 2 indicates that the IPsec security association (SA) parameters—specifically the encryption algorithm, authentication algorithm, or Diffie-Hellman group—do not match between the two FortiGate peers. Phase 2 uses these proposals to negotiate the IPsec SA for protecting data traffic, and a mismatch prevents the tunnel from establishing. Since Phase 1 completed successfully, the pre-shared keys and gateway IP are already verified, isolating the issue to Phase 2 configuration.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The firewall policy allowing the VPN traffic is missing
Why it's wrong here
The absence of a firewall policy for VPN traffic does not directly interfere with IPsec Phase 2 SA negotiation. Phase 2 (IKE Quick Mode or IKEv2 CREATE_CHILD_SA) uses the already-established IKE SA to agree on IPsec SA parameters, whereas firewall policies act on the resulting encrypted packets in the data plane. Without a matching policy, the FortiGate would simply drop the tunneled user traffic after encapsulation/decapsulation, but the control-plane Phase 2 exchange itself could still complete if the proposal settings are compatible. Consequently, a missing policy explains a black hole for data, not a Phase 2 negotiation failure.
- ✓
The Phase 2 encryption and authentication algorithms do not match between peers
Why this is correct
Phase 2 negotiation requires both peers to select an identical set of encryption and authentication algorithms for the IPsec SA, such as AES256-GCM or AES128-SHA256, along with matching DH group and optional PFS. If the Phase 2 proposals are not aligned, the initiator's SA payload cannot find an acceptable combination in the responder's proposal list, causing a 'no proposal chosen' error and preventing the IPsec SAs from being created. This occurs after Phase 1 has already succeeded, which is exactly the symptom of a Phase 2-specific failure, such as when the tunnel status shows Phase 1 up but Phase 2 down.
- ✗
The pre-shared keys do not match
Why it's wrong here
The pre-shared key is used during IKE Phase 1 authentication (in Main Mode, Aggressive Mode, or the IKEv2 SA_INIT/AUTH exchange) to prove identity and generate keying material. If the PSKs did not match, the IKE SA would never be established, and you would see Phase 1 failure long before any Phase 2 activity. Since the issue in question is isolated to Phase 2, the pre-shared key must have already authenticated successfully on both ends; therefore, a PSK mismatch is not a viable cause for the Phase 2 mismatch.
- ✗
The remote gateway IP address is incorrect
Why it's wrong here
The remote gateway IP address is the peer's public or interface address used for the IKE UDP 500/4500 packets; if it were incorrect, Phase 1 would fail because no IKE peer could be reached or responded. An IPsec tunnel cannot progress to Phase 2 unless Phase 1 completes, so a wrong remote gateway eliminates the entire IKE session rather than causing a Phase 2-specific problem. The fact that the failure is at Phase 2 implies that the remote gateway address is correct and reachable, allowing IKE to proceed to the next stage.
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
One of 773 original NSE4 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.