NSE7 Advanced VPN and Zero Trust Practice Question
A FortiGate administrator is troubleshooting an IKEv2 VPN tunnel that fails to establish. The remote peer logs show 'no acceptable proposal' error. Which TWO possible causes should the administrator check?
⚠ Common exam trap
NSE7 often tests the distinction between Phase 1 proposal failures ('no acceptable proposal') and Phase 2 or authentication failures (PSK mismatch, proxy-ID mismatch), so candidates wrongly pick PSK or reachability for a proposal error.
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 phase1 encryption algorithm or integrity algorithm is mismatched
The 'no acceptable proposal' error in IKEv2 specifically indicates that the responder could not find a matching proposal in the IKE_SA_INIT exchange, which is typically caused by a mismatch in the phase1 encryption algorithm (e.g., AES256 vs 3DES) or integrity algorithm (e.g., SHA256 vs SHA1) between the two peers. Option E is also correct because the Diffie-Hellman group is part of the IKEv2 SA proposal; if one peer offers a DH group (e.g., group 14) that the other peer does not support or has not configured, the responder rejects the proposal with the same 'no acceptable proposal' error. Option A is not correct because an unreachable peer would produce timeout or no-response errors rather than a proposal rejection, since the IKE exchange would never reach the proposal comparison stage. Option C is not correct because an IKE version mismatch (IKEv1 vs IKEv2) would cause the peers to fail to parse each other's messages entirely, resulting in different errors such as 'invalid major version' or no response, not 'no acceptable proposal'. Option D is not correct because an incorrect pre-shared key is detected during the IKE_AUTH exchange after the proposal has already been accepted, producing an authentication failure error rather than a proposal rejection.
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 remote peer's IP address is unreachable
Why it's wrong here
An unreachable peer prevents any IKE exchange, so the remote peer would log timeouts or no response, never a proposal mismatch. It is tempting because reachability is a first troubleshooting step, and it would be correct when the tunnel shows no responder at all.
- ✓
The phase1 encryption algorithm or integrity algorithm is mismatched
Why this is correct
A mismatch in phase1 encryption or integrity algorithms causes the responder to reject the initiator's proposal, producing the 'no acceptable proposal' error. IKEv2 requires both peers to agree on identical encryption and integrity algorithms during SA negotiation, so verifying these settings on both gateways resolves the failure.
- ✗
The local FortiGate has the wrong IKE version configured
Why it's wrong here
An IKE version mismatch causes the peers to ignore each other's exchanges entirely, yielding no response rather than a proposal rejection. It is tempting because version errors do break negotiations, and it would be correct when one peer runs IKEv1 and the other IKEv2.
- ✗
The remote peer's pre-shared key is incorrect
Why it's wrong here
A mismatched pre-shared key fails IKEv2 authentication after proposals are accepted, producing an authentication failure rather than 'no acceptable proposal'. It is tempting because PSK errors are common, and checking it would be correct when the tunnel stalls at the authentication exchange instead.
- ✓
The Diffie-Hellman group configured is not supported by both peers
Why this is correct
A Diffie-Hellman group mismatch causes the IKEv2 SA payload to offer a transform the remote peer cannot match, producing the 'no acceptable proposal' error. Since phase 1 requires both peers to agree on the DH group, verifying that each side lists a common group resolves this specific negotiation failure.
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 718 original NSE7 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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Fortinet exam blueprint
This NSE7 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 NSE7 exam.