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 the 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 the authentication infrastructure.
In a transparent web proxy setup without user interaction, users should not be prompted for credentials if the configuration is correct. If users are being asked for credentials, consider the Authentication method:
Active Authentication: User Interaction Required: The FortiGate prompts users to enter credentials, typically via a captive portal or browser-based login:
- LDAP (Lightweight Directory Access Protocol).
- RADIUS (Remote Authentication Dial-In User Service).
- TACACS+ (Terminal Access Controller Access-Control System Plus).
- SAML (Security Assertion Markup Language).
- NTLM (NT LAN Manager).
- Basic Authentication.
- Digest authentication.
- Form-based authentication.
- Negotiate.
Passive Authentication: No User Interaction: The FortiGate attempts to automatically identify the user without prompting. like:
- FSSO (Fortinet Single Sign-On).
- RSSO (RADIUS Single Sign-On).
- Terminal Services Agent (TSA) / TS Agent.
- FortiAuthenticator as a Passive Source.
- Cert..
- SSH-publickey
The scenario described here includes a transparent proxy setup with basic authentication (Active Authentication Method) 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.
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
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 the GUI:
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 is 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 the 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
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 a transparent proxy, a pop-up 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 the defined users/groups in the proxy policy.
- If the cookie expires/is deleted on the browser/a new browser is used, a new authentication prompt appears.
