NSE4 Authentication and VPN Practice Question
During an SSL VPN tunnel mode connection, the client reports that they cannot access any internal resources, but the VPN connection is established. The FortiGate debug shows 'no matching policy'. The administrator has configured a policy allowing the SSL VPN interface to internal. What else must be configured?
⚠ Common exam trap
Many candidates assume that because the VPN connection is established and a policy exists allowing the SSL VPN interface, the traffic should pass, but they overlook that the policy's incoming interface must be explicitly set to the SSL VPN virtual interface (e.g., 'ssl.root') rather than the physical WAN interface.
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
✓
Ensure the incoming interface of the policy is set to 'ssl.root' (or the SSL VPN interface)
The SSL VPN tunnel mode creates a virtual interface (typically named 'ssl.root' or 'ssl.VDOM') on the FortiGate. Even though the administrator configured a policy allowing the SSL VPN interface to internal, the incoming interface in the policy must explicitly be set to this SSL VPN interface. If it is set to a different interface (e.g., the physical WAN interface), the FortiGate will not match the traffic from the SSL VPN tunnel, resulting in the 'no matching policy' debug message.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Ensure the incoming interface of the policy is set to 'ssl.root' (or the SSL VPN interface)
Why this is correct
The firewall policy that permits SSL VPN tunnel traffic must use the SSL VPN logical interface (ssl.root) as its incoming interface. When the client establishes a tunnel, the FortiGate terminates the encrypted session on ssl.root and assigns the virtual IP, so packets from the client enter through that interface, not the physical WAN. If the policy's incoming interface is set to WAN or any other interface, the policy lookup fails and the traffic is dropped.
- ✗
Add the client's assigned IP to a local user group
Why it's wrong here
Local user groups are designed for authentication and authorization, not for traffic matching in firewall policies. The client's dynamically assigned tunnel IP is not a group membership attribute, and FortiGate does not evaluate group membership when performing interface-based policy checks. While group membership can affect SSL VPN portal or realm selection, it has no bearing on the policy's source interface matching for post-authentication traffic.
- ✗
Configure a static route on the FortiGate for the client's tunnel IP
Why it's wrong here
A static route for the client's tunnel IP is unnecessary because the FortiGate automatically installs a host route to each SSL VPN client's assigned IP via the ssl.root interface when the tunnel comes up. This dynamic route is managed by the SSL VPN daemon and already directs return traffic correctly. Adding a static route would either conflict with the existing dynamic route or be redundant, and it does not resolve a firewall policy interface mismatch.
- ✗
Enable split tunneling on the SSL VPN portal
Why it's wrong here
Split tunneling controls which destination networks the client sends through the encrypted tunnel versus directly out its local internet connection. This setting modifies the client-side routing table, not the FortiGate's policy matching, and it does not affect the incoming interface on which tunneled traffic arrives. Even when split tunneling is enabled, the traffic that is tunneled still arrives on the ssl.root interface and still requires the firewall policy to have that interface configured as the source.
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 →
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.