FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
Article Id 205238



This article expands upon the FortiGate cookbook here:

It illustrates in greater detail how to configure a transparent, session-based proxy with web cookies used for authentication.




Any supported version of FortiGate.




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



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.




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:


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





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




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>




This address needs to be referenced in the authentication settings:


config authentication setting

    set captive-portal <address>



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:






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.