Configuring FortiGate Explicit Proxy with Upstream Proxy Chaining and Client IP Preservation

When deploying a FortiGate firewall as an explicit web proxy with Active Directory (AD) authentication, you might need to forward client requests to an upstream proxy while preserving the original client IP. This setup is common in environments requiring detailed user tracking or compliance with specific security policies. In this post, I’ll walk you through how to configure FortiGate to achieve this, including web filtering considerations and handling upstream proxy failures—all based on a real-world scenario I’ve recently tackled.

The Setup: Explicit Proxy with AD Authentication

In explicit proxy mode, clients configure their browsers to send HTTP/HTTPS requests to FortiGate’s proxy IP and port (e.g., 192.168.1.1:8080). With AD authentication enabled, FortiGate validates user credentials against an AD server before processing requests. Here’s a basic configuration:

bash

config user ldap
    edit "AD_server"
        set server "192.168.1.10"
        set port 389
        set dn "DC=example,DC=com"
        set type regular
        set username "ldap_user"
        set password "ldap_password"
    next
end
config web-proxy explicit
    set status enable
    set interface "lan"
    set http-incoming-port 8080
end
config firewall proxy-policy
    edit 1
        set proxy explicit-web
        set srcintf "lan"
        set dstintf "wan1"
        set srcaddr "all"
        set dstaddr "all"
        set service "webproxy"
        set action accept
        set identity-based enable
        set users "AD_users"
    next
end

This setup ensures users are authenticated before their requests are processed. But what if you need to forward these requests to an upstream proxy without altering the client’s source IP?

Proxy Chaining with Client IP Preservation

FortiGate supports proxy chaining via a forwarding server, and it includes an option to use the client’s IP instead of the firewall’s interface IP when sending requests upstream. This is configured under the web-proxy forward-server settings with the set use-client-ip command.

Here’s how to set it up:

bash

config web-proxy forward-server
    edit "upstream_proxy"
        set ip <upstream_proxy_ip>
        set port <upstream_proxy_port>
        set use-client-ip enable
    next
end
config firewall proxy-policy
    edit 1
        set proxy explicit-web
        set srcintf "lan"
        set dstintf "wan1"
        set srcaddr "all"
        set dstaddr "all"
        set service "webproxy"
        set action accept
        set identity-based enable
        set users "AD_users"
        set webproxy-forward-server "upstream_proxy"
    next
end

• Default Behavior: Without set use-client-ip, FortiGate uses its WAN interface IP (e.g., 203.0.113.1) as the source IP for forwarded requests.
• With use-client-ip enable: The request retains the client’s IP (e.g., 192.168.1.100), allowing the upstream proxy to see the original source. This is ideal for auditing or when the upstream proxy applies policies based on client IPs.

Note: For this to work, the upstream proxy must be reachable from the client’s subnet (e.g., on the LAN or via internal routing). If it’s an external proxy, private client IPs may not be routable over the internet, and you might need to rely on the X-Forwarded-For header instead.

Web Filtering and FortiGuard

FortiGate can still perform web filtering locally before forwarding requests:

• It queries FortiGuard for URL categories and applies policies (e.g., blocking social media).
• If a request is blocked, it doesn’t reach the upstream proxy.

To route FortiGuard queries through the upstream proxy, configure:

bash

config system fortiguard
    set proxy-server-ip <upstream_proxy_ip>
    set proxy-server-port <upstream_proxy_port>
end

This adds a dependency on the upstream proxy’s availability, so test thoroughly.

Handling Upstream Proxy Failure

If the WAN link or upstream proxy fails, FortiGate’s explicit proxy continues to accept client connections on its LAN IP, returning an error page unless cached content is available. To signal clients of the failure, you can monitor the upstream proxy’s health and disable the LAN interface when it’s unreachable. Here’s an automation stitch to do it:

bash

config system link-monitor
    edit "upstream_check"
        set srcintf "wan1"
        set server "<upstream_proxy_ip>"
        set protocol http
        set port <upstream_proxy_port>
        set interval 10
        set failtime 3
    next
end
config system automation-action
    edit "disable_lan"
        set action-type cli-script
        set script "config system interface\nedit 'lan'\nset status down\nnext\nend"
    next
end
config system automation-trigger
    edit "upstream_fail"
        set event-type link-down
        set link-monitor "upstream_check"
    next
end
config system automation-stitch
    edit "shutdown_lan_on_proxy_fail"
        set trigger "upstream_fail"
        set action "disable_lan"
    next
end

• How It Works: The link monitor checks the upstream proxy every 10 seconds. After 3 failures (30 seconds), it triggers the script to shut down the LAN interface, disconnecting clients and signaling the issue.
• Recovery: Add a similar stitch with set status up to restore the interface when the proxy recovers.

Key Takeaways

• Client IP Preservation: Use set use-client-ip enable to forward requests with the original client IP.
• AD Authentication: Works seamlessly in explicit mode before forwarding.
• Web Filtering: Can be local or proxied, depending on your FortiGuard setup.
• Failure Handling: Automate LAN shutdown to manage upstream proxy outages.

This configuration balances functionality and reliability. Test it in your environment to ensure routing and the upstream proxy align with your network design. Have you tried a similar setup? Share your thoughts in the comments!