Transparent Proxy Concepts

Transparent Proxy Concepts

In addition to the Explicit Web Proxy, FortiOS supports a Transparent web proxy. While it does not have as many features as Explicit Web Proxy, the transparent proxy has the advantage that nothing needs to be done on the user’s system to forward supported web traffic over to the proxy. There is no need to reconfigure the browser or publish a PAC file. Everything is transparent to the end user, hence the name. This makes it easier to incorporate new users into a proxy deployment.

You can use the transparent proxy to apply web authentication to HTTP traffic accepted by a firewall policy. In previous versions of FortiOS, web authentication required using the explicit proxy.

Normal FortiOS authentication is IP address based. Users are authenticated according to their IP address and access is allowed or denied based on this IP address. On networks where authentication based on IP address will not work you can use the Transparent Web proxy to apply web authentication that is based on the user’s browser and not on their IP address. This authentication method allows you to identify individual users even if multiple users on your network are connecting to the FortiGate from the same IP address.

More about the transparent proxy

The following changes are incorporated into Transparent proxy, some of which affect Explicit Web Proxy as well.

Flat policies

The split policy feature has been removed. This will make the explicit policy more like the firewall policy.

Authentication

The authentication design is intended to separate authentication from authorization. Authentication has been moved into a new table in the FortiOS. This leaves the authorization as the domain of the explicit proxy policy.

Previously, if authentication was to be used:

  1. The policy would be classified as an identity based policy
  2. The policy would be split to add the authentication parameters
  3. The authentication method would be selected
  4. The user/group would be configured Now:

The user/group is configured in the proxy policy

  1. A new authentication rule is added
  2. This option refers to the authentication scheme
  3. The authentication scheme has the details of the authentication method The new authentication work flow for Transparent Proxy:

Toggle the transparent-http-policy match:

Transparent Proxy Concepts

config firewall profile-protocol-options edit <profile ID> config http set http-policy <enable|disable>

If disabled, everything works like before. If enabled, the authentication is triggered differently.

  • http-policy work flow:
  • For transparent traffic, if there is a regular firewall policy match, when the Layer 7 check option is enabled, traffic will be redirected to WAD for further processing.
  • For redirected traffic, layer 7 policy (HTTP policy) will be used to determine how to do security checks.
  • If the last matching factor is down to user ID, then it will trigger a new module to handle the L7 policy user authentication.
  • Then propagate learned user information back to the system so that it can be used to match traffic for L4 policy.

New Proxy Type

There is a new subcategory of proxy in the proxy policy called Transparent Web. The old Web Proxy is now referred to as Explicit Web Proxy.

  • This is set in the firewall policy l It is available when the HTTP policy is enabled in the profile-protocol options for the firewall policy l This proxy type supports OSI layer 7 address matching.
  • This proxy type should include a source address as a parameter l Limitations:
  • It can be used for HTTPS traffic, if deep scanning is not used l It only supports SNI address matching, i.e. domain names l It does not support header types of address matching l It only supports SSO authentication methods, no active authentication methods.

IP pools support

Proxies are now supported on outgoing IP pools.

SOCKSv5

SOCKSv5 authentication is now supported for explicit proxies.

To configure:

config authentication rule edit <name of rule> set protocol socks end

Forwarding

Proxies support URL redirect/forwarding. This allows a non-proxy forwarding server to be assigned a rule that will redirect web traffic from one URL to another, such as redirecting traffic destined for youtube.com to restrict.youtube.com.

Concepts

l A new option called “Redirect URL” has been added to the policy l Traffic forwarding by VIP is supported

Support for explicit proxy address objects & groups into IPv4 firewall policies

This would allow the selection of web filter policy, SSL inspection policy, and proxy policy based on source IP + destination (address|explicit proxy object|category|group of any of those). This enables things like “do full SSL interception on www.google.com, but not the rest of the Search Engines category”.

Support application service in the proxy based on HTTP requests.

The application service can be configured using the following CLI commands:

config firewall service custom edit <name of service> set explicit-proxy enable set app-service-type <disable|app-id|app-category> set app-category <application category ID, integer> set application <application ID, integer> end

This entry was posted in FortiGate, FortiOS 5.6 on by .

About Mike

Michael Pruett, CISSP has a wide range of cyber-security and network engineering expertise. The plethora of vendors that resell hardware but have zero engineering knowledge resulting in the wrong hardware or configuration being deployed is a major pet peeve of Michael's. This site was started in an effort to spread information while providing the option of quality consulting services at a much lower price than Fortinet Professional Services. Owns PacketLlama.Com (Fortinet Hardware Sales) and Office Of The CISO, LLC (Cybersecurity consulting firm).

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.