NSE4 Authentication and VPN Practice Question
A FortiGate administrator is troubleshooting a dial-up IPsec VPN where remote users can connect but traffic does not pass. The Phase 1 and Phase 2 status show 'up'. The administrator runs 'diagnose vpn tunnel list' and sees the tunnel is up. However, 'diagnose sys session list' shows no sessions for the remote user's IP. What is the MOST likely cause?
⚠ Common exam trap
It's easy for candidates to assume an 'up' Phase 1 and Phase 2 guarantee traffic flow, but FortiGate requires a separate firewall policy to permit traffic from the IPsec interface to the destination, and the absence of sessions in 'diagnose sys session list' is the key diagnostic clue for this missing policy.
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
✓
There is no firewall policy permitting traffic from the dial-up interface to the destination network
Even when Phase 1 and Phase 2 are up and the tunnel is established, traffic will not pass through a dial-up IPsec VPN unless a firewall policy explicitly permits traffic from the dial-up interface (often the virtual IPsec interface) to the destination network. The 'diagnose sys session list' showing no sessions for the remote user's IP confirms that the FortiGate is not processing any traffic for that user, which points to a missing or misconfigured firewall policy rather than an encryption or routing issue.
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 Phase 2 proposal uses AES256 but the remote client only supports AES128
Why it's wrong here
If the Phase 2 proposal were mismatched, the IPsec SA negotiation would fail and the tunnel would not come up at all. Since the tunnel is established and the problem is that user traffic is not passing, the proposals must have been successfully negotiated with matching cipher and integrity algorithms. Therefore, a mismatch in AES key lengths cannot be the cause of post-negotiation traffic loss.
- ✗
The FortiGate's routing table does not have a route to the remote user's subnet
Why it's wrong here
In a dial-up VPN scenario, the remote user's IP address is dynamically assigned, so the FortiGate typically relies on a static route pointing toward the dial-up tunnel interface or a per-user host route learned from IKE. If the FortiGate lacked such a route, return packets from the destination network could not be sent back, but the symptom of no sessions suggests the initial forward packets are being dropped before any session creation. Missing routes usually manifest as asymmetric routing or ICMP unreachable messages, not a clean absence of sessions when a policy drop is the culprit.
- ✓
There is no firewall policy permitting traffic from the dial-up interface to the destination network
Why this is correct
The FortiGate's implicit deny rule silently discards any traffic that does not match an explicit firewall policy, including traffic arriving from a dial-up IPsec tunnel interface. Even if the Phase 1 and Phase 2 SAs are fully up, the FortiGate will not forward packets from the remote VPN user to the internal destination unless a policy exists allowing that traffic between the VPN interface (e.g., ssl.root or dialup) and the destination zone. Since the session table is empty, the packets are being dropped by the firewall policy lookup, making a missing policy the most direct and common cause.
- ✗
The remote user's FortiClient is blocking split tunneling
Why it's wrong here
Split tunneling controls which destination networks the FortiClient routes directly vs. through the IPsec tunnel; blocking it would force all client traffic into the tunnel, not prevent it from doing so. If split tunneling were disabled, we would expect to see more sessions and traffic hitting the FortiGate's tunnel interface, yet the session table shows no traffic at all. The absence of any sessions indicates the packets are not reaching the FortiGate or are being explicitly dropped by policy rather than being influenced by client-side routing decisions.
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.