NSE4 Authentication and VPN Practice Question
A FortiGate administrator has configured a route-based IPsec VPN. After Phase 2 is up, traffic is not passing. The administrator verifies that the firewall policy allows traffic and the routes are correct. What should the administrator check next?
⚠ Common exam trap
Many exam-takers assume Phase 2 being up guarantees traffic flow, overlooking that route-based VPNs require the static route to explicitly use the tunnel interface as the outgoing interface, not just any valid next-hop.
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 static route uses the VPN interface as the outgoing interface
In a route-based IPsec VPN, traffic is routed to the VPN tunnel interface (e.g., 'to_remote'). Even if firewall policies and static routes exist, the static route must explicitly use the VPN interface as the outgoing interface. If the static route points to a different interface or a next-hop IP instead of the tunnel interface, the kernel will not forward traffic into the IPsec tunnel, causing Phase 2 to be up but no traffic to pass. This is a common misconfiguration that breaks the route-based VPN model.
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 static route uses the VPN interface as the outgoing interface
Why this is correct
In a route-based VPN, the virtual IPsec interface serves as the tunnel endpoint, and the static route must specify that interface as the outgoing interface for the remote subnet. Without this route, the FortiGate has no entry in its routing table to direct traffic into the IPsec tunnel, even if Phase 1 and Phase 2 SAs are fully established. The route triggers the actual forwarding decision, causing the kernel to encapsulate and encrypt matching traffic over the tunnel.
- ✗
The remote gateway's IP address is reachable
Why it's wrong here
The remote gateway's public address has already been proven reachable because Phase 2 is up, which necessarily means Phase 1 completed successfully over the network path between the two peers. Reachability of the remote gateway is a prerequisite for building the IPsec tunnel, not a condition that controls whether the tunnel is used for a given subnet after establishment. Thus, this option is redundant and does not identify the critical prerequisite for sending data through a route-based tunnel.
- ✗
The pre-shared key is correct
Why it's wrong here
A correct pre-shared key is required for IKE Phase 1 authentication, and if the pre-shared key were invalid, the tunnel would never have come up. Since the administrator has already confirmed that Phase 2 is active, the PSK has already been validated by both peers during the IKE handshake. Consequently, PSK correctness is a necessary but already-met condition that cannot be the missing factor allowing traffic to traverse the route-based VPN.
- ✗
The Phase 2 proposal includes the correct local and remote subnets
Why it's wrong here
In a route-based IPsec VPN, Phase 2 selectors (proxy IDs) are typically configured as 0.0.0.0/0 to avoid subnet-specific matching, allowing the routing table to dictate which destination networks are sent through the tunnel. Unlike policy-based VPNs, the local and remote subnets are not part of the Phase 2 proposal; they are determined by static routes and firewall policies. Therefore, specifying correct local and remote subnets in Phase 2 is neither required nor relevant once the tunnel is already up.
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.