Fortinet white logo
Fortinet white logo

Administration Guide

Key considerations of network settings in Reverse Proxy mode

Key considerations of network settings in Reverse Proxy mode

1. Network Interfaces

Two network interfaces

Ideally, FortiWeb is typically configured with two network interfaces:

  • One for client-side (WAN) traffic

  • One for server-side (LAN) traffic

This separation helps simplify routing, improve performance, and enhance security by logically isolating external and internal traffic flows.

Single Network interface

However, FortiWeb can also operate with a single interface, where FortiWeb:

  • Receives client traffic (e.g., from the internet) on that interface

  • Forwards server traffic to a different subnet via routing

To make this work:

  • You must define a default gateway (or appropriate static routes) on FortiWeb

  • That gateway/router must be able to route traffic to the back-end servers (e.g., 192.0.2.0/24)

Example setup of single network interface

  • Interface port1: IP: 20.0.2.1/24. This is the only interface used.

  • VIP configured: 20.0.2.100 (DNS entry of your app points to this)

  • Back-end servers: 192.0.2.0/24

  • Default Gateway: 20.0.2.254 (a router that can reach both 20.0.2.1/24 and 192.0.2.0/24)

FortiWeb receives traffic for 20.0.2.100, applies load balancing, and sends requests to 192.0.2.x. The gateway routes it correctly.

Related configuration guides:

2. SSL/TLS Configuration (If Using HTTPS)

In the Reserve Proxy mode FortiWeb acts as an SSL proxy. It terminates the HTTPS connection from the client and presents a server certificate to prove its authority for your application domain.

After decrypting and inspecting the traffic, FortiWeb establishes a new connection to the back-end server, which can be either encrypted (HTTPS) or unencrypted (HTTP), depending on the configuration between FortiWeb and the server. This back-end connection is entirely independent of the front-end connection.

Because FortiWeb handles the SSL handshake with the client, you must upload your CA-signed server certificate to FortiWeb so it can present it on behalf of your application and validate the domain’s authenticity.

Related configuration guides:

3. Client IPs in Reverse Proxy mode

In Reverse Proxy Mode, FortiWeb terminates the client session and then establishes a new session with the back-end web server. As a result:

  • The web server does not see the real IP address of the client.

  • Instead, it sees FortiWeb’s IP address as the source of incoming requests.

Since some web applications need the real client IP (e.g., for rate limiting, logging, or geographical analysis), FortiWeb allows you to insert or append the client’s original IP into an HTTP header X-Forwarded-For (XFF).

This resolves the issue, as most modern web servers (e.g., Apache, Nginx, IIS) can be configured to trust the X-Forwarded-For header and use it instead of the direct source IP. For details on configuring these headers, see Indicating the original client’s IP to back-end web servers.

However, if the web server cannot process HTTP headers to extract the real client IP, consider enabling Client Real IP in FortiWeb's server policy. This allows FortiWeb to use the client's IP as the source IP for its connection with the backend server. Proper network configuration is required to ensure the responses are routed back through FortiWeb and further to the correct next-hop gateway. Failure to do so may result in application inaccessibility. For more details, see the description of the Client Real IP option in Configuring an HTTP server policy.

4. DNS Configuration

Assign the IP address associated with your application domain to FortiWeb as the Virtual Server’s listening IP. When configuring the Server Policy, select this Virtual Server to handle incoming client traffic.

5. Back-end Server Configuration
  • Firewall Rules: Allow traffic only from FortiWeb’s LAN IP (e.g., 192.0.2.1).

Key considerations of network settings in Reverse Proxy mode

Key considerations of network settings in Reverse Proxy mode

1. Network Interfaces

Two network interfaces

Ideally, FortiWeb is typically configured with two network interfaces:

  • One for client-side (WAN) traffic

  • One for server-side (LAN) traffic

This separation helps simplify routing, improve performance, and enhance security by logically isolating external and internal traffic flows.

Single Network interface

However, FortiWeb can also operate with a single interface, where FortiWeb:

  • Receives client traffic (e.g., from the internet) on that interface

  • Forwards server traffic to a different subnet via routing

To make this work:

  • You must define a default gateway (or appropriate static routes) on FortiWeb

  • That gateway/router must be able to route traffic to the back-end servers (e.g., 192.0.2.0/24)

Example setup of single network interface

  • Interface port1: IP: 20.0.2.1/24. This is the only interface used.

  • VIP configured: 20.0.2.100 (DNS entry of your app points to this)

  • Back-end servers: 192.0.2.0/24

  • Default Gateway: 20.0.2.254 (a router that can reach both 20.0.2.1/24 and 192.0.2.0/24)

FortiWeb receives traffic for 20.0.2.100, applies load balancing, and sends requests to 192.0.2.x. The gateway routes it correctly.

Related configuration guides:

2. SSL/TLS Configuration (If Using HTTPS)

In the Reserve Proxy mode FortiWeb acts as an SSL proxy. It terminates the HTTPS connection from the client and presents a server certificate to prove its authority for your application domain.

After decrypting and inspecting the traffic, FortiWeb establishes a new connection to the back-end server, which can be either encrypted (HTTPS) or unencrypted (HTTP), depending on the configuration between FortiWeb and the server. This back-end connection is entirely independent of the front-end connection.

Because FortiWeb handles the SSL handshake with the client, you must upload your CA-signed server certificate to FortiWeb so it can present it on behalf of your application and validate the domain’s authenticity.

Related configuration guides:

3. Client IPs in Reverse Proxy mode

In Reverse Proxy Mode, FortiWeb terminates the client session and then establishes a new session with the back-end web server. As a result:

  • The web server does not see the real IP address of the client.

  • Instead, it sees FortiWeb’s IP address as the source of incoming requests.

Since some web applications need the real client IP (e.g., for rate limiting, logging, or geographical analysis), FortiWeb allows you to insert or append the client’s original IP into an HTTP header X-Forwarded-For (XFF).

This resolves the issue, as most modern web servers (e.g., Apache, Nginx, IIS) can be configured to trust the X-Forwarded-For header and use it instead of the direct source IP. For details on configuring these headers, see Indicating the original client’s IP to back-end web servers.

However, if the web server cannot process HTTP headers to extract the real client IP, consider enabling Client Real IP in FortiWeb's server policy. This allows FortiWeb to use the client's IP as the source IP for its connection with the backend server. Proper network configuration is required to ensure the responses are routed back through FortiWeb and further to the correct next-hop gateway. Failure to do so may result in application inaccessibility. For more details, see the description of the Client Real IP option in Configuring an HTTP server policy.

4. DNS Configuration

Assign the IP address associated with your application domain to FortiWeb as the Virtual Server’s listening IP. When configuring the Server Policy, select this Virtual Server to handle incoming client traffic.

5. Back-end Server Configuration
  • Firewall Rules: Allow traffic only from FortiWeb’s LAN IP (e.g., 192.0.2.1).