Description
This article expands upon the FortiGate cookbook here: https://docs.fortinet.com/document/fortigate/6.2.0/cookbook/15908/transparent-proxy.
It illustrates in greater detail how to configure a transparent, session-based proxy with web cookies used for authentication.
Scope
Any supported version of FortiGate.
Solution
FortiOS offers the option of a transparent proxy setup if connections should be proxied without the user being aware, or if no specific configuration (such as with explicit proxy) should be required on the client host.
A transparent proxy on FortiGate intercepts HTTP/HTTPS traffic and redirects it to the proxy internally. FortiGate will open a session to the destination server itself, and match the two sessions (client to FortiGate, and FortiGate to server) to the authentication rules and proxy policies in place.
For authentication, there are two fundamental options – IP-based, and session-based.
With IP-based authentication, users authenticate once, their IP is considered authenticated until configured timeouts apply. This is commonly used in scenarios where each user has their own IP.
With session-based authentication, users are required to authenticate again for each new session; this is commonly used in scenarios where users are likely to share an IP (terminal servers, guest computers).
However, in cases of active authentication (such as using basic authentication), this means users may need to authenticate on every single web-page they visit.
Any passive authentication (such as NTLM or Kerberos) also requires web-cookie settings to be enabled to reduce the number of authentications that FortiGate triggers in the background and avoid overwhelming authentication infrastructure.
The scenario described here includes a transparent proxy setup with basic authentication and web-cookies.
It works similarly for NTLM, form-based authentication and other options offered.
The complete configuration consists of interface and proxy settings, interface settings, IPv4 policy, authentication settings, rule and scheme, and a proxy policy.
All settings are per-VDOM.
1) Enable explicit proxy.
For a transparent proxy to be possible, explicit proxy needs to be enabled under System -> Feature Select to make proxy policies and other configuration times available.
If required, enable this through the CLI:
config system settings
set gui-proxy-inspection enable
end
Additionally, the following interface configuration needs to be set via CLI for the interface the transparent proxy should be associated with:
# config system interface
edit <interface>
set proxy-captive-portal enable <----- This needs to be enabled.
next
end
2) IPv4 policy.
An IPv4 policy needs to be configured to redirect the user traffic to transparent proxy.
This policy MUST have deep inspection enabled (which can lead to certificate errors).
To resolve certificate errors due to deep inspection, refer to this document: https://docs.fortinet.com/document/fortigate/5.4.0/cookbook/329138/preventing-certificate-warnings
In addition, the policy MUST be in proxy mode.
Once a policy is in place, the following needs to be configured via CLI:
config firewall policy
edit <policy ID>
set http-policy-redirect enable
next
end
Note.
The policy ID can be found in the policy overview by adding the column ID (via right-click on a column).
The policy will then look like this in GUI:
3) Authentication settings.
For web-cookie authentication to work, some authentication settings are required, including an authentication scheme and rule.
The authentication scheme defines what authentication method (basic, NTLM, Kerberos, etc) is used, and against what database (local/LDAP/etc) the user is checked.
Authentication schemes can be configured under Policy & Objects -> Authentication Rules, by clicking on 'Scheme' in the upper right corner.
In this example, the method is Basic, and the user database an LDAP server.
The authentication rule defines what source IPs will utilize what authentication scheme.
In this example, the authentication scheme 'basic' is applied to all sources that trigger proxy traffic.
IP-based authentication is disabled, making this a session-based rule.
Further settings are required via CLI:
config authentication rule
edit <rule>
set ip-based disable
set web-auth-cookie enable
next
end
In addition, for transparent proxy to handle the cookie properly, a firewall address with an FQDN resolving to the FortiGate interface is required:
config firewall address
edit <address>
set type fqdn
set fqdn <an FQDN resolving to proxy-interface IP>
next
end
This address needs to be referenced in the authentication settings:
config authentication setting
set captive-portal <address>
end
4) Proxy policy.
As the last step, a proxy policy is required:
The proxy policy should contain users/groups in source that match the user database defined in step 3).
In this example, the 'ldap-proxy' group references the 'win-server' LDAP server:
Conclusion:
With these settings in place:
- If a user opens a browser to access websites through transparent proxy, a popup asking for credentials appears.
- The credentials are checked against the defined user database.
- If successful, the user is issued a web-cookie.
- FortiGate allows the user if they match into the defined users/groups in proxy policy.
- If the cookie expires/is deleted on the browser/a new browser is used, a new authentication prompt appears.
