How to set up your FortiWeb : Planning the network topology : Topology for reverse proxy mode
 
Topology for reverse proxy mode
This is the default operation mode, and the most common. Most features are supported (see “Supported features in each operation mode”).
Requests are destined for a virtual server’s network interface and IP address on FortiWeb, not a web server directly. FortiWeb usually applies full NAT.
 
DNS A/AAAA record changes may be required in reverse proxy mode due to NAT. Also, servers will see the IP of FortiWeb, not the source IP of clients, unless you configure FortiWeb to insert/append to an HTTP X-header such as X-Forwarded-For:. Verify that the server does not apply source IP-based features such as rate limiting or geographical analysis, or, alternatively, that it can be configured to find the original client’s source IP address in an HTTP X-header.
If you want to deploy without any IP and DNS changes to the existing network, consider either of the transparent modes instead.
Figure 13: Example network topology: reverse proxy mode
FortiWeb applies the first applicable policy, then forwards permitted traffic to a web server. FortiWeb logs, blocks, or modifies violations according to the matching policy.
Figure 13 shows an example network topology for reverse proxy mode. A client accesses two web servers over the Internet through a FortiWeb appliance. A firewall is installed between FortiWeb and the Internet to regulate non-HTTP/HTTPS traffic. Port1 is connected to the administrator’s computer. Port2 is connected to the firewall. Port3 is connected to a switch, which is connected to the web servers. The FortiWeb appliance provides load-balancing between the two web servers.
Alternatively, Figure 14 shows multiple protocols originating from the client. Only HTTP/HTTPS is routed through FortiWeb for additional scanning and processing before arriving at the servers.
Figure 14: Example network topology: one-arm with reverse proxy mode
 
Virtual servers can be on the same subnet as physical servers. This is one way to create a one-arm HTTP proxy. For example, the virtual server 192.0.2.1/24 could forward to the physical server 192.0.2.2.
However, this is often not recommended. Unless your network’s routing configuration prevents it, it could allow clients that are aware of the physical server’s IP address to bypass the FortiWeb appliance by accessing the physical server directly.
 
By default when in reverse proxy mode, FortiWeb will not forward non-HTTP/HTTPS traffic to from virtual servers to your protected back-end servers. (IP-based forwarding/routing of unscanned protocols is disabled.)
If you must forward FTP, SSH, or other protocols to your back-end servers, Fortinet recommends that you do not deploy FortiWeb inline. Instead, use FortiGate VIP port forwarding to scan then send FTP, SSH, etc. protocols directly to the servers, bypassing FortiWeb. Deploy FortiWeb in a one-arm topology where FortiWeb receives only HTTP/HTTPS from the FortiGate VIP/port forwarding, then relays it to your web servers. Carefully test to verify that only firewalled traffic reaches your web servers.
If this is not possible, and you require FortiWeb to route non-HTTP protocols above the TCP layer, you may be able to use the config router setting command. See the FortiWeb CLI Reference. For security and performance reasons, this is not recommended.