Planning the network topology

To receive traffic intended for web servers that your FortiWeb appliance will protect, you usually must install the FortiWeb appliance between the web servers and all clients that access them.

The network configuration should make sure that all network traffic destined for the web servers must first pass to or through the FortiWeb appliance (depending on your operation mode). Usually, clients access web servers from the Internet through a firewall such as a FortiGate, so the FortiWeb appliance should be installed between the web servers and the firewall.

Install a general purpose firewall such as FortiGate in addition to the FortiWeb appliance. Failure to do so could leave your web servers vulnerable to attacks that are not HTTP/HTTPS-based. FortiWeb appliances are not general-purpose firewalls, and, if you enable IP-based forwarding, will allow non-HTTP/HTTPS traffic to pass through without inspection.

Ideally, control and protection measures should only allow web traffic to reach FortiWeb and your web servers. FortiWeb and FortiGate complement each other to improve security.

Other topology details and features vary by the mode in which the FortiWeb appliance will operate. For example, FortiWeb appliances operating in offline protection mode or either of the transparent modes cannot do network address translation (NAT) or load-balancing; FortiWeb appliances operating in reverse proxy mode can.

External load balancers: before or after?

Usually you should deploy FortiWeb in front of your load balancer (such as FortiBalancer, FortiADC, or any other device that applies source NAT), so that FortiWeb is between the load balancer and the clients. This has important effects:

Otherwise, attackers’ and legitimate clients’ IP addresses may be hidden by the load balancer.

Alternatively, depending on the features that you require, you may be able to use FortiWeb’s built-in load balancing features instead. See Load Balancing Algorithm.
Example network topology: Load balancer after FortiWeb

Example network topology: Load balancer before FortiWeb, no X-headers (misconfiguration)

To prevent that, you must configure your devices to compensate for that topology if FortiWeb is behind your load balancer:

FortiWeb often applies blocking at the TCP/IP connection level, which could result in blocking innocent HTTP requests if the load balancer is transmitting them within the same TCP connection as an attack. It could therefore appear to cause intermittent failed requests.

Some features do not support using client IPs found in the X-header. See Defining your proxies, clients, & X-headers.
Example network topology: Load balancer before FortiWeb with X-headers

How to choose the operation mode

Many things, including:

vary by the operation mode. Choose the mode that best matches what you and your customers need. Considerations are discussed in Supported features in each operation mode and Matching topology with operation mode & HA mode.

Because this is such a pivotal factor, consider the implications carefully before you make your choice. It can be time-consuming to reconfigure your network if you switch modes later.

If you are not sure which operation mode is best for you, you can deploy in offline protection mode temporarily. This will allow you to implement some features and gather auto-learning data while you decide.

Supported features in each operation mode

Many features work regardless of the operation mode that you choose. For some features, support varies by the operation mode. For example, rewriting requires an inline topology and synchronous processing, and therefore is only supported in modes that work that way.

For the broadest feature support, choose reverse proxy mode.

If you require a feature that is not supported in your chosen operation mode, such as DoS protection or SSL/TLS offloading, configure your web server or another network appliance to provide that feature. The table below lists the features that are not universally supported in all modes/protocols.

Feature support that varies by operation mode
Feature Operation mode
Reverse proxy True transparent proxy Transparent inspection Offline protection WCCP
Bridges / V-zones No Yes Yes No No
Caching Yes Yes No No Yes
Client Certificate Verification Yes Yes No No Yes
Config. Sync

(Non-HA)
Yes ^ Yes Yes Yes Yes
Cookie Security Yes Yes No No Yes
CSRF Protection Yes Yes No No Yes
Device Tracking Yes Yes No No Yes
DoS Protection Yes Yes No No Yes
Error Page Customization Yes Yes No No Yes
Fail-to-wire No Yes Yes No Yes
File Compression Yes Yes No No Yes
Hidden Input Constraints Yes Yes No No Yes
HA (Active-passive) Yes Yes Yes No Yes
HA (Active-active) Yes Yes No No No
HTTP Header Security Yes Yes No No Yes
HTTP/2 Support Yes Yes No No No
HTTP Content Routing Yes No No No No
Information Disclosure Prevention

(Anti-Server Fingerprinting)
Yes Yes Yes§ Yes Yes
Network Firewall Yes No No No No
OCSP Stapling Yes No No No No
Page Order Rules Yes Yes No No Yes
Rewriting / Redirection Yes Yes No No Yes
Session Management Yes Yes* Yes* Yes* Yes*
Site Publishing Yes Yes No No Yes
SSL/TLS Offloading Yes No No No No
SSLv3, TLS 1.0/1.1/1.2 Support Yes Yes~ Yes~ Yes~ Yes~
SSLv2 Support Yes No No No No
Start Page Enforcement Yes Yes No No Yes
User Authentication Yes Yes No No Yes
X-Forwarded-For: Support Yes Yes No No Yes
^ Full configuration sync is not supported in reverse proxy mode.

§ Only the Alert action is supported.

* Requires that your web application have session IDs. See Session Key.

~ DSA-encrypted server certificates are not supported.

Diffie-Hellman key exchanges are not supported.

For the specific cipher suites that FortiWeb supports in each operating mode and protocol, see Supported cipher suites & protocol versions.
 

Matching topology with operation mode & HA mode

Required physical topology varies by your choice of operation mode. It also varies depending on whether you will operate a high availability (HA) cluster of FortiWeb appliances. You may need to consider 1 or 2 of the next sections:

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.
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.

Example network topology: reverse proxy mode 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, Example network topology: one-arm with reverse proxy mode shows multiple protocols originating from the client. Only HTTP/HTTPS is routed through FortiWeb for additional scanning and processing before arriving at the servers.

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.

Topology for either of the transparent modes

No changes to the IP address scheme of the network are required. Requests are destined for a web server, not the FortiWeb appliance. More features are supported than offline protection mode, but fewer than reverse proxy, and may vary if you use HTTPS (see also Supported features in each operation mode).

Unlike with reverse proxy mode, with both transparent modes, web servers will see the source IP address of clients.

You can configure VLAN subinterfaces on FortiWeb, or omit IP address configuration entirely and instead assign a network port to be a part of a Layer 2-only bridge.

In both transparent modes, the appliance will forward non-HTTP/HTTPS protocols. (That is, routing /IP-based forwarding for unscanned protocols is supported.) This facilitates pass-through of other protocols such as FTP or SSH that may be necessary for a true drop-in, transparent solution.
Example network topology: transparent modes

Example network topology: transparent modes shows one example of network topology for either true transparent proxy or transparent inspection mode. A client accesses a web server over the Internet through a FortiWeb appliance. A firewall is installed between the FortiWeb appliance and the Internet to regulate non-HTTP/HTTPS traffic. Port1 is connected to the administrator’s computer. Port3 is connected to the firewall. Port4 is connected to the web servers. Port3 and port4 have no IP address of their own, and act as a V-zone (bridge). Because port3 and port4 have hardware support for fail-to-wire, this topology also gives you the option of configuring fail-open behavior in the event of FortiWeb power loss.

True transparent proxy mode and transparent inspection mode are the same in topology aspect, but due to differences in the mode of interception, they do have a few important behavioral differences:

Unlike in reverse proxy mode or true transparent proxy mode, actions other than Alert cannot be guaranteed to be successful in transparent inspection mode. The FortiWeb appliance will attempt to block traffic that violates the policy. However, due to the nature of asynchronous inspection, the client or server may have already received the traffic that violated the policy.

Topology for offline protection mode

Out-of-band” is an appropriate descriptor for this mode. Minimal changes are required. It does not introduce any latency. However, many features are not supported (see Supported features in each operation mode).

Most organizations do not permanently deploy their FortiWeb in offline protection mode. Instead, they will use it as a way to learn about their web servers’ vulnerabilities and to configure some of the FortiWeb during a transition period, after which they will switch to an operation mode that places the appliance inline (between clients and web servers).

Switching out of offline protection mode when you are done with transition can prevent bypass problems that can arise as a result of misconfigured routing. It also offers you the ability to offer protection features that cannot be supported in a SPAN port topology.

Requests are destined for a web server, not the FortiWeb appliance. Traffic is duplicated from the flow and sent on an out-of-line link to the FortiWeb through a switched port analyzer (SPAN or mirroring) port. Unless there is a policy violation, there is no reply traffic from FortiWeb. Depending on whether the upstream firewalls or routers apply source NAT (SNAT), the web servers might be able to see and use the source IP addresses of clients.

Example network topology: offline protection mode

FortiWeb monitors traffic received on the data capture port’s network interface (regardless of the IP address) and applies the first applicable policy. Because it is not inline with the destination, it does not forward permitted traffic. FortiWeb logs or blocks violations according to the matching policy and its protection profile. If FortiWeb detects a malicious request, it sends a TCP RST (reset) packet through the blocking port to the web server and client to attempt to terminate the connection. It does not otherwise modify traffic. (It cannot, for example, offload SSL, load-balance connections, or support user authentication.)

Unlike in reverse proxy mode or true transparent proxy mode, actions other than Alert cannot be guaranteed to be successful in offline protection mode. The FortiWeb appliance will attempt to block traffic that violates the policy by mimicking the client or server and requesting to reset the connection. However, the client or server may receive the reset request after it receives the other traffic due to possible differences in routing path metrics and latency.

 

If you select offline protection mode, you can configure Blocking Port to select the port from which TCP RST (reset) commands are sent to block traffic that violates a policy.

Example network topology: offline protection mode shows an example one-arm network topology for offline protection mode. A client accesses two web servers over the Internet through a FortiWeb appliance. A firewall is installed between the FortiWeb appliance and the Internet to regulate non-HTTP/HTTPS traffic. Port1 is connected to the administrator’s computer. Port2 is connected to the firewall, and thereby to a switch, which is connected to the web servers. The FortiWeb appliance provides detection, but does not load-balance, block, or otherwise modify traffic to or from the two web servers.

Alternatively, you could connect a FortiWeb appliance operating in offline protection mode to the SPAN port of a switch.

Topology for WCCP mode

WCCP mode does not require changes to the IP address scheme of the network. Requests are destined for a web server and not the FortiWeb appliance. This operation mode supports the same feature set as true transparent proxy mode (see Supported features in each operation mode). However, like reverse proxy mode, web servers see the FortiWeb network interface IP address and not the IP address of the client.

Example network topology: WCCP mode

In the illustration Example network topology: WCCP mode, a client accesses a web server over the Internet through a FortiWeb appliance. In this one-arm topology, a firewall is configured as a WCCP server that routes HTTP/HTTPS traffic arriving on port1 to a FortiWeb configured as a WCCP client. The firewall directs non-HTTP/HTTPS traffic to the switch directly. On the FortiWeb, Port3 is configured for the WCCP protocol and connected to the firewall.

FortiWeb applies the first applicable policy, logs, blocks, or modifies violations according to the matching policy, and then returns permitted traffic to the firewall. The firewall is configured to route HTTP/HTTPS traffic arriving on port3 to the switch.

Topologies for high availability (HA) clustering

Valid HA topologies vary by whether you use either:

Example network topology: reverse proxy mode with active-passive HA shows another network topology for reverse proxy mode, except that the single FortiWeb appliance has been replaced with two of them operating together as an active-passive (high availability (HA) pair. If the active appliance fails, the standby appliance assumes the IP addresses and load of the failed appliance.

To carry heartbeat and synchronization traffic between the HA pair, the heartbeat interface on both HA appliances must be connected through crossover cables or through switches.

Example network topology: reverse proxy mode with active-passive HA

If you use a switch to connect the heartbeat interfaces, they must be reachable by Layer 2 multicast.

If FortiWeb will not be operating in reverse proxy mode (such as for either true transparent proxy mode or transparent inspection mode), typically you would not use FortiWeb HA — this could require changes to your network scheme, which defeats one of the key benefits of the transparent modes: it requires no IP changes. Instead, most customers use an existing external load balancer/HA solution in conjunction with FortiWeb configuration synchronization to preserve an existing active-active or active-passive topology, as shown in Example network topology: transparent proxy mode with configuration synchronization and external HA via FortiADC.

If the operation mode is not reverse proxy mode (for example, the mode is true transparent proxy or transparent inspection), use configuration synchronization or FortiWeb Manager to maintain consistent configuration settings between the HA Active-Active units. The illustration shows an example of an HA topology that uses configuration synchronization.

Example network topology: reverse proxy mode with active-active HA

This example shows another HA topology for reverse proxy mode; an active-active HA deployment. A FortiWeb active-active HA cluster cab be consisted of more than two FortiWeb appliances (up to eight). All the cluster members are operating as an active appliance together, which means each of the members can simultaneously handle the traffic between clients and the back web servers. In the active-active HA cluster, there is one appliance selected as the master and in the meantime time the others are slaves. Like a central controller, only the master appliance receives traffic from clients and back web servers, then it will distribute received traffic to all the cluster members (including itself), so that each FortiWeb appliance performs the security services to protect the traffic.

Similar to the active-passive HA deployment, the operation of active-active HA cluster requires heartbeat detection, configuration and session synchronization between the cluster members. If the master appliance fails, one of the slaves will take it over. The heartbeat interfaces of all the HA appliances must be connected directly with crossover cables or through switches to carry the heartbeat and synchronization traffic between the HA cluster members.

Example network topology: transparent proxy mode with configuration synchronization and external HA via FortiADC

Unlike with FortiWeb HA, the external HA device detects when a FortiWeb has failed and then redirects the traffic stream. (FortiWeb has no way of actively notifying the external HA device.) To monitor the live paths through your FortiWebs, you could configure your HA device to poll either:

You can use configuration synchronization to replicate the FortiWeb configuration without HA(that is, no load balancing and no failover). Configuration synchronization has no special topology requirement, except that synchronized FortiWebs should be placed in identical topologies. For more information, see Configuring a high availability (HA) FortiWeb cluster.
See also