NSE4 Authentication and VPN Practice Question
A FortiGate administrator is configuring a route-based IPsec VPN between two FortiGate devices. After setting up the tunnel and firewall policies, traffic does not flow. The administrator runs 'diagnose vpn tunnel list' and sees the tunnel is up. 'get router info routing-table all' shows routes on both sides. However, pings from the local network to the remote network fail. What is the MOST likely cause?
⚠ Common exam trap
Watch out — candidates often assume a tunnel being up and routes present guarantees traffic flow, overlooking that the firewall policy's interface direction must match the traffic flow, not the tunnel's logical direction.
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 firewall policy allowing traffic to the remote subnet has the source and destination interfaces reversed
The tunnel is up and routes are present, indicating Phase 1 and Phase 2 negotiations succeeded. The most likely cause is that the firewall policy allowing traffic to the remote subnet has the source and destination interfaces reversed. In a route-based VPN, the policy must have the incoming interface as the source (e.g., internal) and the outgoing interface as the destination (e.g., the VPN tunnel interface). Reversing these prevents traffic from being matched, even though the tunnel is established.
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 pre-shared key is incorrect
Why it's wrong here
An incorrect pre-shared key would fail during Phase 1 IKE authentication, producing an authentication failure (often an INVALID_KEY_INFORMATION or AUTHENTICATION_FAILED notify) before the IKE SA is established. Because the tunnel remains down and no Phase 2 SA can exist, this explanation does not match the reported symptom where the tunnel is up but data is dropped. The PSK is never involved once Phase 1 is active; it cannot cause traffic to be silently discarded after SAs exist.
- ✓
The firewall policy allowing traffic to the remote subnet has the source and destination interfaces reversed
Why this is correct
In a route-based VPN, the policy must be configured with the VPN interface as the destination interface (if traffic flows from internal to VPN) or source interface (if from VPN to internal). Misconfiguration here causes traffic to be dropped.
- ✗
The remote FortiGate's static route points to the wrong local subnet
Why it's wrong here
The remote FortiGate's static route is used only on the peer side to steer return traffic into the tunnel; if it pointed to the wrong local subnet, responses from the remote LAN would be sent to an incorrect destination or dropped. However, the problem description states that routes are correct and present in the routing table, so a misconfigured remote route is not the cause. A local policy/interface mismatch remains the more likely culprit because route-based VPN requires consistent routes and a correctly oriented firewall policy.
- ✗
The Phase 2 proposal uses different encryption algorithms on each side
Why it's wrong here
If the Phase 2 proposals specified different encryption or integrity algorithms on each peer, the IKEv2 or IKEv1 Quick Mode exchange would fail with a NO_PROPOSAL_CHOSEN notice and no IPsec SA would be installed. Since the tunnel status shows Phase 2 as up, the two FortiGates have already negotiated matching transforms, including encryption, authentication, and DH group. Once an IPsec SA is active, the negotiated algorithms are fixed and cannot cause later traffic drops without rekey failure.
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
One of 282 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.