NSE4 Authentication and VPN Practice Question
A FortiGate admin configures a remote user for SSL VPN tunnel mode. The user can connect but cannot access resources on the internal network. The admin checks the SSL VPN settings: tunnel mode enabled, split tunneling disabled. What is the issue?
⚠ Common exam trap
Many exam-takers assume a successful VPN connection automatically grants access to internal resources, overlooking the mandatory firewall policy that must explicitly permit traffic from the SSL VPN interface to the internal network.
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 from the SSL VPN interface to the internal network is missing or incorrectly configured
When split tunneling is disabled, all traffic from the SSL VPN client is expected to be routed through the FortiGate. However, even with the tunnel established, the FortiGate must have a firewall policy that permits traffic from the SSL VPN interface (e.g., ssl.root) to the internal network interface, with the appropriate source (the user's assigned IP pool) and destination. Without this policy, packets are dropped by the FortiGate's implicit deny rule, preventing access to internal resources.
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 user's FortiClient is outdated
Why it's wrong here
Outdated FortiClient versions are generally still capable of establishing an SSL VPN tunnel; FortiGate's SSL VPN endpoint negotiates with legacy clients using backward-compatible TLS and DTLS parameters. While Fortinet recommends a current version for feature parity and security patches, an older build rarely prevents connectivity, so it cannot explain why the tunnel is up but internal resources are unreachable.
- ✗
The SSL certificate is expired
Why it's wrong here
An expired SSL certificate on the FortiGate would cause the SSL/TLS handshake to fail before the VPN session is initialized; both FortiClient and web mode would display a certificate error and terminate the connection. The user would never receive an IP address from the VPN range, nor would a tunnel interface become active, making this a connection-establishment blocker rather than a post-connectivity issue.
- ✓
The firewall policy from the SSL VPN interface to the internal network is missing or incorrectly configured
Why this is correct
After the SSL VPN tunnel interface comes up, the FortiGate enforces its implicit-deny policy without a matching firewall rule; to reach internal servers, an explicit policy must exist with source set to the SSL VPN interface (e.g., ssl.vpn or ssl.root), destination set to the internal network, and appropriate services/action. A missing or misconfigured policy, such as using the wrong protocol, source address, or interface, silently drops the user's packets, which perfectly matches the symptom of a successful login but no access to internal resources.
- ✗
The user's client software is not configured to route all traffic through the tunnel
Why it's wrong here
Split tunneling is a server-side setting configured in the SSL VPN portal, not a standalone FortiClient misconfiguration; when the FortiGate's portal has split tunnel enabled, the client only routes specific subnets through the VPN, but when disabled, the FortiGate forces all traffic into the tunnel. If split tunneling is enabled and the user's destination subnet is not listed, the traffic bypasses the tunnel, yet the remedy would be adjusting the split-tunnel list, not the client's generic 'route all' toggle — and the correct answer points to the missing firewall policy that would still govern allowed tunneled destinations.
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
Courseiva writes every NSE4 question from scratch — 773 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.