NSE4 Authentication and VPN Practice Question
An administrator is troubleshooting an IPsec VPN between two FortiGates. Phase 1 is up but Phase 2 is down. The admin runs 'diagnose vpn ike log' and sees 'no matching proposal'. To resolve this issue, which TWO settings should be checked on both ends?
⚠ Common exam trap
Watch out — candidates often confuse Phase 1 and Phase 2 parameters, assuming that a Phase 1 mismatch (like encryption algorithm or authentication method) could cause a Phase 2 'no matching proposal' error, when in fact Phase 2 has its own independent set of proposals including PFS and encryption 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
✓
Phase 2 PFS (Perfect Forward Secrecy) group
The 'no matching proposal' error during Phase 2 negotiation means the two peers cannot agree on the Phase 2 (IPsec SA) parameters, so the administrator must verify the Phase 2 proposal settings on both ends. Option A is correct because the Phase 2 PFS (Perfect Forward Secrecy) group (e.g., DH group 5, 14, 19) is part of the Phase 2 proposal; if one side enables PFS with a different DH group than the other, or one side omits PFS entirely, the proposals will not match and Quick Mode will fail. Option D is correct because the Phase 2 encryption algorithm (e.g., AES128, AES256) must be identical on both peers; a mismatch in the encryption transform is a classic cause of 'no matching proposal' at Phase 2. Options B and E are incorrect because the Phase 1 authentication method and Phase 1 encryption algorithm are negotiated during Phase 1 (Main/Aggressive Mode), and since Phase 1 is already up, those parameters have already matched successfully. Option C is incorrect because the Phase 2 local and remote subnets are the selectors used to build the IPsec SA; a subnet mismatch typically causes traffic to not match the tunnel or produces a 'no policy' or traffic-selector error, not a 'no matching proposal' error.
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 PFS (Perfect Forward Secrecy) group
Why this is correct
Phase 2 'no matching proposal' commonly stems from PFS group mismatch. If one peer enables Perfect Forward Secrecy with a specific Diffie-Hellman group and the other uses a different group or disables PFS, the Phase 2 proposal cannot match, so both ends must use identical PFS settings.
- ✗
Phase 1 authentication method
Why it's wrong here
Phase 1 authentication is validated during Phase 1, which is already established, so a mismatch there would have prevented Phase 1 from coming up. It is tempting because authentication mismatches are a classic IPsec fault, but they surface as Phase 1 failures, not Phase 2 proposal errors.
- ✗
Phase 2 local and remote subnets
Why it's wrong here
While mismatched subnets can cause issues, the error 'no matching proposal' typically refers to algorithms/PFS, not selectors. However, sometimes selectors are included in the proposal; but the two most common causes are encryption and PFS.
- ✓
Phase 2 encryption algorithm (e.g., AES128, AES256)
Why this is correct
Phase 2 encryption algorithm mismatch causes 'no matching proposal' because the two peers cannot agree on a cipher for the IPsec SA. Verifying that both ends specify the same algorithm, such as AES256 or AES128, ensures the Phase 2 proposal matches and the tunnel completes negotiation.
- ✗
Phase 1 encryption algorithm
Why it's wrong here
Phase 1 encryption is negotiated and completed before Phase 2 begins; since Phase 1 is up, its algorithm already matches, so it cannot cause the Phase 2 'no matching proposal' error. It is tempting because encryption mismatches do break IPsec, but only at the phase whose proposal is failing.
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
Courseiva writes every NSE4 question from scratch — 773 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.