NSE4 Authentication and VPN Practice Question
You are troubleshooting an IPsec VPN between two FortiGates. The Phase 1 is up, but Phase 2 is not coming up. You check the Phase 2 configuration on both sides. What is a common cause of this issue?
⚠ Common exam trap
Test-takers frequently confuse Phase 1 and Phase 2 issues, assuming any mismatch in authentication or encryption must be Phase 1, but FortiGate separates these phases, and Phase 2 mismatches are a distinct and common cause of partial VPN failure.
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
✓
Mismatch in Phase 2 settings such as encryption algorithm, authentication algorithm, or PFS group
When Phase 1 is up but Phase 2 fails, the most common cause is a mismatch in Phase 2 parameters. Phase 2 uses IPsec SA proposals that must match exactly on both sides, including encryption algorithm (e.g., AES256), authentication algorithm (e.g., SHA256), and Perfect Forward Secrecy (PFS) group (e.g., DH14). Even a single mismatch, such as one side using PFS and the other not, will prevent Phase 2 from establishing.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Mismatch in Phase 2 settings such as encryption algorithm, authentication algorithm, or PFS group
Why this is correct
Phase 2 negotiation (Quick Mode in IKEv1) is separate from Phase 1 and uses its own proposal set. For a FortiGate-to-FortiGate VPN, the encryption algorithm (e.g., AES128 vs AES256), authentication/HMAC algorithm (e.g., SHA1 vs SHA256), and Perfect Forward Secrecy (PFS) group (e.g., None vs DH14) must match exactly on both peers. If PFS is enabled on one side but not the other, or the DH groups differ, Phase 2 will fail with a proposal or no-proposal-match error even though Phase 1 is healthy.
- ✗
Firewall policy not allowing ESP traffic
Why it's wrong here
A firewall policy blocking ESP (IP protocol 50) would prevent user data from traversing the tunnel, but it would not prevent Phase 2 from completing. Phase 2 Quick Mode (IKEv1) or IKE_AUTH exchanges (IKEv2) ride over the existing UDP 500/4500 IKE channel established during Phase 1, not over ESP. Therefore, if Phase 1 is up, the IKE negotiate channel exists, so Phase 2 can still negotiate; ESP blocking would only manifest as traffic drop after the SAs are created. This option is thus not the cause of a Phase 2 bring-up failure.
- ✗
Incorrect local or remote gateway IP
Why it's wrong here
The local and remote gateway IP addresses are used in initial IKE contact to establish Phase 1. If either IP were incorrect, the peers could not reach each other, and Phase 1 would never come up. Since the symptom states Phase 1 is up, the gateway IPs must be correctly configured and routable. Moreover, Phase 2 reuses the same IKE channel; it does not re-verify peer addresses, so incorrect gateway IPs cannot cause a selective Phase 2 failure.
- ✗
Mismatch in Phase 1 pre-shared key
Why it's wrong here
The pre-shared key is only used during IKE Phase 1 authentication (e.g., Main Mode/MM or Aggressive Mode/AM). If the keys did not match, the peers would generate different SKEYID and fail authentication, resulting in Phase 1 not reaching active status. The fact that Phase 1 is up proves the pre-shared keys matched on both sides. Since Phase 2 relies on the already-established IKE security association, a key mismatch from Phase 1 cannot cause a Phase 2 failure—it is a zero possibility.
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.