NSE4 Authentication and VPN Practice Question
A network administrator is troubleshooting an IPsec VPN tunnel between two FortiGates. Phase 1 is up, but Phase 2 fails to establish. The debug command 'diagnose vpn ike log' shows: 'no suitable proposal found'. What is the most likely cause?
⚠ Common exam trap
A common mix-up: candidates confuse Phase 1 and Phase 2 proposal errors, assuming any 'no suitable proposal found' message relates to Phase 1, but the context of Phase 1 being up explicitly isolates the issue to Phase 2 parameter mismatch.
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
✓
Phase 2 encryption or authentication algorithms do not match on both sides.
The 'no suitable proposal found' error in Phase 2 of an IPsec VPN tunnel indicates that the Phase 2 parameters (encryption algorithm, authentication algorithm, or PFS settings) do not match between the two FortiGate peers. Since Phase 1 is up, the IKE SA is established, meaning pre-shared keys, remote gateway reachability, and basic firewall policies for IKE traffic are correct. The mismatch specifically occurs in the Phase 2 proposal negotiation, where each side sends its supported transforms and the responder cannot find a common set.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Phase 2 encryption or authentication algorithms do not match on both sides.
Why this is correct
Phase 2 (Quick Mode) negotiates the IPsec SA parameters, including the encryption algorithm (e.g., AES-256, 3DES) and authentication algorithm (e.g., SHA-1, SHA-256) for the ESP/AH protocol. If the local and remote firewalls do not offer a common proposal for these algorithms and the Diffie-Hellman group, the Phase 2 negotiation will fail with an error such as 'no proposal chosen.' Since Phase 1 has already formed a secure IKE SA, the problem isolates specifically to a Phase 2 proposal mismatch, preventing the tunnel from establishing even though both gateways are reachable and authenticated.
- ✗
The firewall policy allowing IPsec traffic is missing.
Why it's wrong here
A firewall policy that permits IPsec traffic governs which data flows are allowed to traverse an established VPN tunnel, but it does not drive the IKE Phase 2 negotiation itself. In route-based VPNs the tunnel can establish with no policy present, and in policy-based VPNs the policy's local/remote selectors must match the Phase 2 proxy IDs, but a missing policy would show symptoms like dropped traffic or no matching policy, not a failure to create the Phase 2 IPsec SA. Therefore, if Phase 2 is not coming up, the root cause is not the absence of a firewall policy.
- ✗
The remote gateway IP address is unreachable.
Why it's wrong here
If the remote gateway IP address were unreachable, the FortiGate would be unable to send IKE packets, and Phase 1 would never complete. Because Phase 2 negotiation is only initiated after a successful Phase 1, a reachability failure would abort the process before Phase 2 is ever attempted. Since the administrator observes a Phase 2 failure, the Phase 1 SA exists, which proves the remote gateway is reachable over the network, eliminating this option as the cause.
- ✗
The pre-shared key is incorrect.
Why it's wrong here
An incorrect pre-shared key is used in IKE Phase 1 to authenticate the peers—not in Phase 2. If the PSK does not match, authentication during Phase 1 Main Mode or Aggressive Mode exchange fails, and no IKE SA is established. Thus the Phase 2 Quick Mode would never be invoked, so a PSK mismatch cannot be the explanation for a Phase 2-specific failure; this issue would prevent Phase 1 entirely.
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
Courseiva writes every NSE4 question from scratch — 282 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.