NSE4 Authentication and VPN Practice Question
A network administrator configures an IPsec VPN between two FortiGate devices. Phase 1 completes successfully, but Phase 2 fails to establish. The administrator runs 'diagnose vpn ike log' and sees the error 'proposal mismatch'. What is the MOST likely cause?
⚠ Common exam trap
Watch out — candidates often confuse Phase 1 and Phase 2 failures: because Phase 1 completed, they might incorrectly suspect pre-shared key or IKE version issues, but the 'proposal mismatch' error is specific to Phase 2 parameters like subnets or encryption settings.
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 local and remote subnets do not match on both ends
The error 'proposal mismatch' in the Phase 2 IKE log indicates that the IPsec security associations (SAs) proposed by one FortiGate do not match the configured Phase 2 parameters on the other. Since Phase 1 completed successfully, the IKE version and pre-shared key are already validated. The mismatch specifically refers to the local and remote subnet definitions, encryption algorithms, or authentication methods in the Phase 2 selectors. Therefore, the most likely cause is that the Phase 2 local and remote subnets are not correctly mirrored on both ends.
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 IKE version is mismatched (IKEv1 vs IKEv2)
Why it's wrong here
A mismatch between IKEv1 and IKEv2 is detected during Phase 1 (the IKE_SA_INIT exchange in IKEv2, or Main/Aggressive Mode in IKEv1), where peers exchange SA proposals with different payload structures and mandatory attributes. Without an established IKE SA, there is no authenticated and encrypted channel over which Phase 2 (Quick Mode or CREATE_CHILD_SA) can run. Consequently, the failure manifests as a Phase 1 negotiation error, not a Phase 2 proposal mismatch.
- ✗
The pre-shared key is incorrect
Why it's wrong here
An incorrect pre-shared key causes authentication failure during IKE Phase 1 (or the IKE_AUTH exchange in IKEv2), because each peer derives a keyed hash using the PSK and verifies it against the peer's response. If the keys do not match, the IKE SA is never established. Phase 2 is only initiated after the IKE SA is active, and its parameters, including traffic selectors, are never discussed—so this scenario cannot produce a Phase 2 proposal mismatch.
- ✗
The firewall policies are blocking IKE traffic on UDP port 500
Why it's wrong here
IKE negotiation relies on UDP port 500 (and UDP 4500 for NAT traversal); if a firewall policy blocks these ports, the IKE SA cannot be formed because the initial SA proposal packets are dropped. Without the IKE SA, Phase 2 cannot even begin, as its messages are encapsulated and encrypted inside the IKE SA. Therefore, the failure would appear as a Phase 1 timeout or no-response error, not a proposal mismatch, which is a logical parameter incompatibility and would occur even when the network path is fully open.
- ✓
The Phase 2 local and remote subnets do not match on both ends
Why this is correct
During Phase 2, both peers exchange proxy IDs (traffic selectors) that define the exact local and remote subnets to be protected. For the IPsec SA to be established, the local selector on each peer must be the mirror image of the remote selector on the other peer. If the configured subnets differ on either side (for example, 192.168.1.0/24 versus 192.168.2.0/24), the IKE daemon rejects the proposal with a 'no proposal chosen' error, which is a Phase 2 proposal mismatch. While encryption or integrity algorithms can also cause a Phase 2 failure, mismatched subnet selectors are the most common issue in policy-based VPNs.
Visual reference
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 282 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.