Troubleshooting SSL VPN Connectivity: Users Connected but No Access to Internal Resources
A FortiGate administrator is troubleshooting an SSL VPN connection issue. Users can connect but cannot access internal resources. The administrator checks the SSL VPN policy and confirms it allows access to the internal subnet. What should the administrator check next?
Quick Answer
The answer is to verify that the firewall policy between the SSL VPN interface and the internal network allows the traffic. Even when an SSL VPN policy correctly permits access to a specific internal subnet, that policy only governs authentication and tunnel assignment; the actual packet forwarding still requires a separate firewall policy on the FortiGate to permit traffic from the SSL VPN interface (typically ssl.root) to the destination internal network. This is a classic two-policy requirement on FortiOS, and the Fortinet NSE 4 exam frequently tests this distinction to catch candidates who assume the SSL VPN policy alone is sufficient. A common trap is overlooking the firewall policy when users are connected but cannot access internal resources, as the connection succeeds at the VPN layer but packets are silently dropped at the security policy layer. Memory tip: think of the SSL VPN policy as the "door key" and the firewall policy as the "hall pass"—both are required to reach the internal network.
⚠ Common exam trap
Many candidates assume the SSL VPN policy alone governs all access, overlooking the separate firewall policy requirement that actually enforces traffic flow between the SSL VPN interface and 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
✓
Verify that the firewall policy between the SSL VPN interface and the internal network allows the traffic
Even if the SSL VPN policy permits access to the internal subnet, traffic must still traverse a firewall policy from the SSL VPN interface (e.g., ssl.root) to the internal network interface. Without an explicit firewall policy allowing the traffic, the FortiGate will drop the packets, preventing resource access. This is a common oversight because the SSL VPN policy only controls tunnel establishment and route injection, not the actual forwarding of traffic between zones.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Verify that the firewall policy between the SSL VPN interface and the internal network allows the traffic
Why this is correct
SSL VPN traffic terminates on the FortiGate, then is re-evaluated against firewall policy before reaching the internal subnet. The SSL VPN portal policy alone does not permit forwarding, so a missing or misordered policy from the SSL VPN interface to the internal network silently drops the traffic.
- ✗
Check the routing table on the FortiGate for the internal subnet
Why it's wrong here
A missing route to the internal subnet would cause the FortiGate to drop or misdirect return traffic, but the SSL VPN policy already permitting that subnet implies reachability is configured. Routing is the right check when the FortiGate itself cannot reach a destination network, not when per-user access is failing after a successful tunnel.
- ✗
Ensure the users have the correct client software installed
Why it's wrong here
Client software is already proven working, since users connect successfully; the failure lies beyond tunnel establishment. Checking it tempts because incompatible or outdated clients do block SSL VPN access entirely, but that scenario produces connection failures, not authenticated sessions that cannot reach internal subnets.
- ✗
Check the FortiGate's DNS settings
Why it's wrong here
DNS resolution affects name lookups, not reachability of an internal subnet the policy already permits; users failing by IP address would still fail. DNS is worth checking when users can reach the gateway but cannot resolve internal hostnames, which is a different symptom from total resource inaccessibility.
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
This NSE4 question is part of Courseiva's 773-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on NSE4
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A FortiGate administrator is troubleshooting an SSL VPN issue where remote users cannot access internal resources after successful authentication. Which TWO steps should the admin take to resolve the issue? (Select two.)
medium- ✓ A.Verify that a firewall policy exists allowing traffic from the SSL VPN interface to the internal network
- B.Increase the authentication timeout
- ✓ C.Check the routing table on the FortiGate to ensure return routes are present
- D.Restart the FortiGate
- E.Disable the SSL VPN portal
Why A: After successful SSL VPN authentication, traffic from the remote user must be permitted by a firewall policy that allows traffic from the SSL VPN interface (e.g., ssl.root) to the destination internal network interface. Without this policy, packets are dropped even if authentication succeeds. Option C is correct because the FortiGate must have a route back to the SSL VPN client IP pool (or the client's virtual IP) in its routing table; if the return route is missing, the FortiGate cannot forward reply traffic to the remote user, causing asymmetric routing and connectivity failure.
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.