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:

Simplified configuration
Un-scanned traffic will not reach your load balancer, improving its performance and security
At the IP layer, from FortiWeb’s perspective, HTTP requests will correctly appear to originate from the real client’s IP address, not (due to SNAT) your load balancer

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. For details, see Load Balancing Algorithm.

This is an example of a network topology with a load balancer behind a FortiWeb:

This is an example of an incorrect configuration in which a load balancer is in front of a FortiWeb and there are no X-headers:

To prevent such an incorrect configuration, you must configure your devices to compensate if FortiWeb is behind your load balancer. Configure your load balancer so that it does not multiplex HTTP requests from different clients into each TCP connection with FortiWeb.

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. To account for this, configure your load balancer to insert or append an X-Forwarded-For:, X-Real-IP:, or other HTTP X-header. Also configure FortiWeb to find the original attacker’s or client’s IP address in that HTTP header, not in the IP session. For details, see Defining your proxies, clients, & X-headers.

Some features do not support using client IPs found in the X-header. For details, see Defining your proxies, clients, & X-headers.

This is an example of a correct configuration in which a load balancer is in front of a FortiWeb and there are X-headers:

Do not set any Action to Period Block if the load balancer, or any other device in front of FortiWeb, applies SNAT unless you have configured blocking based upon HTTP X-headers. Period blocking based upon the source IP address at the IP layer will cause innocent requests forwarded by the SNAT device after an attack to be blocked until the blocking period expires. It could therefore appear to cause intermittent service outages. For details, see Blocking known attacks .

How to choose the operation mode

Many things, including:

Supported FortiWeb features
Required network topology
Positive/negative security model
Web server configuration

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.

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 for each operation mode
Feature	Operation mode
Feature	Reverse Proxy	True Transparent Proxy	Transparent Inspection	Offline Protection	WCCP
HA (Active-passive)	Yes	Yes	Yes	Yes	Yes
HA (Active-active-Standard)	Yes	Yes	No	No	No
HA (Active-active-High Volume)	Yes	No	No	No	No
Bridges/V-zones	No	Yes	Yes	No	No
Network Firewall	Yes	Yes	Yes	No	No
Fail-to-wire	No	Yes	Yes	No	Yes
Config. Sync (Non-HA)	Yes^	Yes	Yes	Yes	Yes
File Upload	Yes	Yes	Yes	Yes	Yes
AJAX Block	Yes	Yes	No	No	Yes
Error Page Customization	Yes	Yes	No	No	Yes
Threat Weight	Yes	Yes	Yes	Yes	Yes
FortiGate Quarantined IPs	Yes	Yes	No	No	Yes
ADFS Policy	Yes	No	No	No	No
HSTS Header	Yes	Yes	No	No	Yes
HPKP Header	Yes	Yes	No	No	Yes
OCSP Stapling	Yes	Yes	No	No	Yes
TLS 1.0/1.1/1.2 Support	Yes	Yes	Yes~¶	Yes~¶	Yes
TLS 1.3 Support	Yes~	Yes~	No	No	Yes~
Client Certificate Forwarding	Yes	Yes	No	No	Yes
Client Certificate Verification	Yes	Yes	No	No	Yes
Statistic	Yes	Yes	Yes	Yes	Yes
User Authentication	Yes	Yes	No	No	Yes
Mobile Application Identification	Yes	Yes	Yes	Yes	Yes
HTTP/2 Support	Yes	Yes	No	No	No
SSL/TLS Offloading	Yes	No	No	No	No
Client Management	Yes	Yes	Yes*	Yes*	Yes*
HTTP Content Routing	Yes	No	No	No	No
Proxy Protocol	Yes	Yes	Yes	Yes	No
Protected Hostnames	Yes	Yes	Yes	Yes	Yes
Traffic Mirror	Yes	Yes	No	No	No
Global allow list	Yes	Yes	Yes	Yes	Yes
X-Forwarded-For: Support	Yes	Yes	Yes	Yes	Yes
URL Rewriting/Redirection	Yes	Yes	No	No	Yes
HTTP Authentication	Yes	Yes	No	No	Yes
Site Publish	Yes	Yes	No	No	Yes
File Compression	Yes	Yes	No	No	Yes
Waiting Room	Yes	Yes	No	No	Yes
Acceleration	Yes	Yes	No	No	Yes
Caching	Yes	Yes	No	No	Yes
Signatures	Yes	Yes	Yes	Yes	Yes
Custom Signature	Yes	Yes	Yes	Yes	Yes
Custom Policy	Yes	Yes	Yes	Yes	Yes
Padding Oracle Security	Yes	Yes	Yes	Yes	Yes
CSRF Protection	Yes	Yes	No	No	Yes
HTTP Header Security	Yes	Yes	No	No	Yes
Man in the Browser Protection Policy	Yes	Yes	No	No	Yes
URL Encryption	Yes	Yes	No	No	Yes
SQL/XSS Syntax Based Detection	Yes	Yes	Yes	Yes	Yes
Cookie Security	Yes	Yes	No	No	Yes
Data Loss Prevention	Yes	Yes	Yes	Yes	Yes
Parameter Validation	Yes	Yes	Yes	Yes	Yes
Hidden Fields	Yes	Yes	Yes	Yes	Yes
HTTP Protocol Constraints	Yes	Yes	Yes	Yes	Yes
WebSocket Security	Yes	Yes	No	No	Yes
Chunk Decode	Yes	Yes	Yes	Yes	Yes
URL Access	Yes	Yes	Yes	Yes	Yes
Allow Method	Yes	Yes	Yes	Yes	Yes
CORS Protection	Yes	Yes	No	No	Yes
Bot Mitigation	Yes	Yes	No	No	Yes
Biometrics Based Detection	Yes	Yes	No	No	Yes
Threshold Based Detection	Yes	Yes	No	No	Yes
Bot Deception	Yes	Yes	No	No	Yes
Known Bots	Yes	Yes	No	No	Yes
JSON Protection	Yes	Yes	Yes	Yes	Yes
XML Protection	Yes	Yes	Yes	Yes	Yes
GraphQL Protection	Yes	Yes	Yes	Yes	Yes
WS-Security Rule	Yes	Yes	No	No	Yes
OpenAPI Validation	Yes	Yes	Yes	Yes	Yes
Mobile API Protection	Yes	Yes	Yes	Yes	Yes
API Gateway	Yes	Yes	Yes	Yes	Yes
HTTP Access Limit	Yes	Yes	No	No	Yes
Malicious IPs	Yes	Yes	No	No	Yes
HTTP Flood Prevention	Yes	Yes	No	No	Yes
TCP Flood Prevention	Yes	Yes	No	No	Yes
DoS Protection	Yes	Yes	No	No	Yes
IP List	Yes	Yes	Yes	Yes	Yes
Geo IP	Yes	Yes	Yes	Yes	Yes
IP Reputation	Yes	Yes	Yes	Yes	Yes
User Tracking	Yes	Yes	Yes	Yes	Yes
ML based Anomaly Detection	Yes	Yes	Yes	Yes	Yes
ML based Bot Detection	Yes	Yes	Yes	Yes	Yes
ML based API Protection	Yes	Yes	No	No	No
ZTNA	Yes	No	No	No	No
^ Full configuration sync is not supported in Reverse Proxy mode. § Only the Alert action is supported. * Requires that your web application have session IDs. For details, 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
Topology for either of the transparent modes
Topology for Offline Protection mode
Topology for WCCP mode
Topologies for high availability (HA) clustering

Topology for Reverse Proxy mode

This is the default operation mode, and the most common. Most features are supported. For details, 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. 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.

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.

This is 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, this is an example that shows multiple protocols originating from the client in a one-arm topology in Reverse Proxy mode:

Only HTTP/HTTPS is routed through FortiWeb for additional scanning and processing before arriving at the servers.

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 from virtual servers to your protected back-end servers. By defaut, IP-based forwarding/routing of unscanned protocols is disabled.

If you must forward FTP, SSH, or other protocols to your back-end servers, we recommend 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. For details, see 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 the pass-through of other protocols such as FTP or SSH that may be necessary for a true drop-in, transparent solution.

This is an example of a 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:

True Transparent Proxy—FortiWeb transparently proxies the traffic arriving on a network port that belongs to a Layer 2 bridge, applies the first applicable policy, and lets permitted traffic pass through. FortiWeb logs, blocks, or modifies violations according to the matching policy and its protection profile. This mode supports user authentication via HTTP but not HTTPS.
Transparent Inspection—FortiWeb asynchronously inspects traffic arriving on a network port that belongs to a Layer 2 bridge, applies the first applicable policy, and lets permitted traffic pass through. (Because it is asynchronous, it minimizes latency.) FortiWeb logs or blocks traffic according to the matching policy and its protection profile, but does not otherwise modify it. 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 Transparent Inspection mode. The FortiWeb appliance will attempt to block traffic that violates the policy. However, due to the nature of asynchronous inspection, before FortiWeb sends the TCP Reset packet to the client or server to terminate the session, the client or server may have already received the traffic that violated the policy, or the session itself may have already ended or been deleted.

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. For details, 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.

This is an example of a network topology in Offline Protection mode:

A client accesses two web servers over the Internet through a FortiWeb. A firewall is installed between the FortiWeb 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 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 operating in Offline Protection mode to the SPAN port of a switch.

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.

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

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.

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. However, like Reverse Proxy mode, web servers see the FortiWeb network interface IP address and not the IP address of the client. For details, see Supported features in each operation mode.

This is an example of a network topology in 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:

FortiWeb active-passive HA
FortiWeb active-active HA
An external HA/load balancer

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.

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

This is an example of a active-passive HA network topology in Reverse Proxy mode:

If the active appliance fails, the standby appliance assumes the IP addresses and load of the failed appliance.

This is an example for an active-active HA network topology in Reverse Proxy mode:

A FortiWeb active-active HA cluster can be consist of up to eight FortiWebs. All the cluster members operate as an active appliance together, which means each of the members can simultaneously handle the traffic between clients and the back web servers. In an active-active HA cluster, there is one appliance selected as the primary and the others are secondary appliances. Like a central controller, only the primary appliance receives traffic from clients and web servers; it will distribute received traffic to the cluster members (including itself), so that each FortiWeb appliance performs the security services to monitor 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 primary appliance fails, one of the secondary appliances 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.

If FortiWeb will not be operating in Reverse Proxy mode, typically you would not configure an HA network topology. Configuring an HA network topology in other operation modes could require changes to your network scheme, which defeats one of the key benefits of other operating modes: they require 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.

This is an example of a network topology in True 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 FortiWeb configuration, you could configure your HA device to poll either:

A back-end web server, or
An IP on each FortiWeb bridge (V-zone)

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 details, see Replicating the configuration without FortiWeb HA (external HA).