NSE4 Authentication and VPN Practice Question
An administrator configures a dial-up IPsec VPN using IKEv2 with certificates. Remote users can connect, but traffic is not routed through the tunnel. The Phase 1 status shows 'up', but Phase 2 shows 'down'. What is the most likely issue?
⚠ Common exam trap
A common mix-up: candidates assume a successful Phase 1 means the entire VPN is working, but NSE4 tests the understanding that Phase 2 must also be up for traffic to flow, and proposal mismatches are the primary cause of Phase 2 failures.
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 proposals do not match between the FortiGate and the client.
In IKEv2 VPNs, Phase 1 establishes the secure control channel (ISAKMP SA) and shows 'up' even if Phase 2 fails. Phase 2 creates the IPsec SA for actual data traffic; if it remains 'down', the most common cause is a mismatch in Phase 2 proposals (encryption, authentication, or PFS settings) between the FortiGate and the remote client. Since the client can connect but traffic is not routed, the tunnel is not fully established for data, pointing directly to a Phase 2 proposal mismatch.
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 firewall policy for the VPN traffic is missing.
Why it's wrong here
A missing firewall policy for VPN traffic would indeed prevent traffic from being forwarded across the tunnel, but it would not cause the Phase 2 quick mode negotiation itself to fail. Phase 2 establishment occurs between the IKE peers before any traffic traverses the tunnel; the FortiGate can successfully bring up the IPsec SA without any firewall policy referencing it. Only after the tunnel is established would traffic be dropped by the lack of policy, and typically the FortiGate logs would show no SAs created if the failure were before that stage.
- ✓
The Phase 2 proposals do not match between the FortiGate and the client.
Why this is correct
In IKEv2, the CREATE_CHILD_SA exchange negotiates the IPsec SA parameters, including encryption, integrity, and DH group. If the FortiGate's configured Phase 2 proposal set does not include at least one transform that exactly matches what the client proposes, the negotiation fails and no Phase 2 SA is established. The Phase 1 IKE SA may still be up, but the tunnel remains down because the two peers cannot agree on a common traffic protection algorithm suite. This is the most direct cause of a failed Phase 2 while Phase 1 is successful.
- ✗
The pre-shared key for Phase 2 is incorrect.
Why it's wrong here
The pre-shared key in an IKEv2 IPsec VPN is used only for authenticating the IKE SA during Phase 1 (IKE_SA_INIT / IKE_AUTH exchanges). Phase 2 does not use a separate pre-shared key; instead, the existing IKE SA's authentication material is used to protect the CREATE_CHILD_SA exchange. Therefore, an incorrect PSK would be detected during Phase 1 authentication, not Phase 2, and would prevent Phase 1 from completing, contradicting the scenario where Phase 1 is already up.
- ✗
The remote user's client does not support IKEv2.
Why it's wrong here
If the remote client did not support IKEv2, the initial IKE_SA_INIT exchange would fail and Phase 1 would never be established. Since the administrator sees that Phase 1 is up, the client must have successfully negotiated IKEv2 and the IKE SA is active. Thus, the client's lack of support for IKEv2 cannot be the cause of a Phase 2 failure in this context; the negotiation already passed that version compatibility point.
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.