Authenticated but Not Authorized on SSL VPN
A FortiGate 80F terminates SSL VPN on wan1:443 with a public certificate. LDAP CORP-AD points to 10.10.5.10. User group VPN-Users uses the LDAP group filter (memberOf=CN=SSL-VPN,OU=Groups,DC=corp,DC=local). FortiToken Cloud MFA is enabled for that group. Portal full has split tunnel disabled, tunnel IP range 10.212.134.200-250, and routing address 10.10.0.0/16. Policy ssl.root -> internal, source all, destination 10.10.0.0/16, group VPN-Users, no NAT. Most users connect and reach 10.10.x. Six users who are members of SSL-VPN-Nested (a group nested inside SSL-VPN) authenticate successfully - the log shows password and token accepted - but receive no tunnel IP and cannot reach anything. Another user connects and reaches 10.10.x but not 172.16.0.0/12.
1. Separate the authentication result from the authorization result for the six nested-group users, and give the fix.
Read the worked answer
Authentication succeeded: the password was verified by LDAP and the FortiToken was accepted. Authorization failed: the FortiGate did not place the user in VPN-Users, so no portal was mapped and no tunnel address was assigned.
The group filter tests the user object's memberOf value. AD's memberOf is not recursive; it lists direct group memberships, not groups inherited through nesting. Users directly in SSL-VPN match; users in SSL-VPN-Nested do not.
Fix options:
- Add the nested group DN to the filter with an OR, for example a filter that matches either CN=SSL-VPN or CN=SSL-VPN-Nested.
- Create a second LDAP group for SSL-VPN-Nested and map it to the same portal.
- Flatten AD membership so VPN users are direct members of SSL-VPN.
The second or third option is usually easier to maintain. Verify with diagnose debug application sslvpn -1 and the LDAP group lookup, not just the authentication log line.
2. Why can the other user reach 10.10.x but not 172.16.0.0/12 when split tunnel is disabled?
Read the worked answer
Split tunnel controls what the client sends into the tunnel; it does not replace the firewall policy. This portal forwards all traffic, but the only policy from ssl.root permits destination 10.10.0.0/16. Traffic to 172.16.x is tunneled and then denied by policy because no rule matches it.
Fix: add a policy or broaden the existing destination to include 172.16.0.0/12, scoped to the required group. If split tunnel is later enabled, the portal's routing address must also include 172.16.0.0/12, or the client will not send that traffic into the tunnel at all.
Confirm with diagnose debug flow filtered on the user's tunnel IP: the drop should show the policy check failing for the 172.16 destination.
3. A month later 60 users connect concurrently and some get no tunnel IP. What is the first thing to check, and what else could produce the same symptom?
Read the worked answer
Check the tunnel IP range first. 10.212.134.200-250 contains 51 addresses. With 60 concurrent users, at least 9 sessions cannot get an address regardless of authentication. The SSL VPN logs usually record an address-exhaustion message, but the user-facing symptom is simply a failed or addressless login.
Other causes to rule out only after the range is confirmed adequate: the user is not matching the group filter, so no portal is mapped; the portal is mapped to a different group; or the SSL VPN settings are bound to the wrong interface. Those produce authorization or binding failures, not exhaustion.
Fix: expand the range, for example 10.212.134.200-250 to a larger subnet, and ensure the range does not overlap internal routes. Capacity planning should use peak concurrent sessions, not the number of accounts.