A field technician's SSL VPN session repeatedly fails right after the technician enters valid credentials, while other technicians using the same portal connect successfully. The FortiGate's event log shows the authentication step succeeding, but the session tears down immediately afterward. Which layer of the problem should the engineer investigate next?
Select an answer to reveal the explanation.
Short Explanation
The log already says authentication worked, and the credentials are fine, so re-checking the password is a dead end. Since it fails right after login and only for this technician, the next place to look is whatever happens after login is confirmed — group mapping, portal assignment, or a posture check.
Full Explanation
Because the FortiGate's log explicitly shows authentication succeeding and the failure happens immediately afterward, and because other technicians on the same portal connect fine, the fault is isolated to something specific to this technician's post-authentication path rather than the portal or credential-validation process itself. Likely candidates include the user or group not being correctly mapped to the SSL VPN portal they're attempting to use, a missing or mismatched user group assignment, or an endpoint compliance/posture check (such as a required security profile) failing silently after login and causing the session to be torn down. SSL VPN does not use a phase 1 pre-shared key in the way site-to-site IPsec does; SSL VPN authentication for user connections relies on the configured authentication method against local, RADIUS, or LDAP, not an IPsec phase 1 PSK, so investigating a phase 1 key is chasing the wrong protocol entirely. Re-examining the username and password is unproductive given the log already confirms successful authentication — the credentials are not the failure point, and continuing to focus there wastes time while the actual post-login step goes unexamined. Phase 2 selectors and DH groups are IPsec VPN concepts tied to the security association between two IKE peers; SSL VPN sessions do not negotiate IPsec phase 2 selectors, so this option misapplies an unrelated VPN technology's terminology to an SSL VPN problem. A practical next step is reviewing the SSL VPN event log in detail (not just the summary), checking the technician's group memberships against the portal's user/group mapping, and confirming any endpoint check configured on that portal isn't rejecting this specific device.