Description
This article describes some inherent restrictions with using SSL-VPN and an explicit proxy setup with authentication.
Scope
FortiGate.
Solution
In setups with Explicit Proxy on FortiGate, where SSL VPN users are also expected to utilize the explicit proxy, there are some inherent restrictions due to how VPN and proxy authentication work that may cause the FortiGate to behave in an unexpected manner.
Proxy authentication and SSL-VPN authentication are separate mechanisms on FortiGate, and handled by different daemons. In effect, proxy authentication is maintained as a separate list of users from other authentication sources (SSL-VPN, FSSO, captive portal, etc).
The proxy daemon can essentially import some pre-existing login information from other sources, like already existing FSSO or SSL-VPN logins, if the matching proxy authentication rule is IP-based. However, this can have some unintended consequences due to group membership information.
In particular, the proxy daemon imports logins 'as is', meaning with group information from the original login. For VPN users for example, this would mean login with the VPN user and any groups that are used in a VPN context (in a policy with VPN source interface) who are a member of, and no other groups.
There is no additional lookup!
As a result, if a VPN user is imported by the proxy daemon for proxy authentication purposes, and proxy policies use different groups than the VPN groups, the user will not match this!
As an example:
User 'debbie' is member of group 'VPN1', 'VPN2' and 'Proxy1'
FortiGate has a VPN policy with groups 'VPN1' and 'VPN2', and a proxy policy with 'Proxy1'.
User 'debbie' connects to VPN on FortiGate, and authenticates successfully.
FortiGate now has a login for user 'debbie' and groups 'VPN1' and 'VPN2'. It does NOT have group membership for 'Proxy1' listed, because that group is NOT used in a VPN context!
User 'debbie' now tries to access Internet via explicit proxy (and through the VPN).
The proxy daemon checks authentication rules; if it finds a matching IP-based one, it also checks for existing logins of the user, finds the VPN login (with groups 'VPN1' and 'VPN2') and imports that. No further checks on the user/groups are done.
The proxy daemon then checks for matching policies. There is only a policy for the group 'Proxy1', but the user 'debbie' will NOT match this because FortiGate is not aware of that group membership at this stage!
More details on SSL-VPN authentication in general:
https://community.fortinet.com/t5/FortiGate/Technical-Tip-A-quick-guide-to-FortiGate-SSL-VPN-authent...
There is an additional constraint when SSL-VPN, FSSO and Proxy are used in combination:
- A user might be authenticated via both SSL-VPN and FSSO at the same time (due to RADIUS Accounting or Mobility Agent, the VPN login might have also generated an FSSO login, for example).
- If that user then tries to access resources via explicit proxy, the explicit proxy will prefer the VPN login over FSSO login at present (Firmware 7.2.2). This is also the case if an FSSO authentication rule for proxy exists!
Possible workarounds
1) Session-based proxy authentication.
If session-based authentication is configured in the authentication rules instead of IP-based, then any proxy user (coming from VPN or not) will trigger a new authentication for each new session, including renewed group lookup. Already known logins are ignored in this case.
Downside.
Each new session and new authentication will trigger a new group lookup, which will increased traffic to authentication servers; in large-scale deployments, this can overwhelm authentication servers if not careful.
2) Using the same user group(s) in VPN and Proxy.
If the same groups are used in VPN and proxy setup, then VPN authentication will of course find and match the proxy groups, and users will match the correct policies based on their group memberships learned from VPN authentication.
Downside.
Some environments/companies require strict separation of groups based on what context they are used in, so there would be dedicated groups for VPN, proxy, internet access, etc.
In that case, this workaround is not possible.
