Defining your web servers

To specify your back-end web servers, you first define a server pool. Pools contain one or more members that you specify using either their IP addresses or DNS domain names. FortiWeb protects these web servers and they are the recipients of traffic that is forwarded or allowed to pass through to by FortiWeb.

You can also define web servers to be FortiWeb’s virtual servers. This chains multiple policies together, which may be useful in more complex traffic routing or rewriting situations.

Configuring server up/down checks

Tests for server availability (called “server health checks” in the web UI) poll web servers that are members of a server pool to determine their responsiveness before forwarding traffic. FortiWeb can check server health using the following methods:

TCP
ICMP ECHO_REQUEST (ping)
TCP Half Open
TCP SSL
HTTP
HTTPS

FortiWeb polls the server at the frequency set in the Interval option. If the appliance does not receive a reply within the timeout period, and you have configured the health check to retry, it attempts a health check again; otherwise, the server is deemed unresponsive. The FortiWeb appliance reacts to unresponsive servers by disabling traffic to that server until it becomes responsive.

If all members of the pool are unresponsive and you have configured one or more members to be backup servers, FortiWeb sends traffic to a backup server.

If a web server will be unavailable for a long period, such as when a server is undergoing hardware repair, it is experiencing extended down time, or when you have removed a server from the server pool, you may improve the performance of your FortiWeb appliance by disabling connectivity to the web server, rather than allowing the server health check to continue to check for responsiveness. For details, see Enabling or disabling traffic forwarding to your servers.

You can create a health check, use one of the predefined health checks, or clone one of the predefined health checks to use as a starting point for a custom health check. (You cannot modify the predefined health checks.)

To simplify health check creation, FortiWeb provides predefined health checks for each of the available protocols. Each predefined health check contains a single rule that specifies one of the available protocols. For example, instead of creating a health check that uses ICMP, you can apply HLTHCK_IMCP.

HLTHCK_HTTP and HLTHCK_HTTPS health checks test server responsiveness using the HEAD method and listening for the response code 200.

Your health check can use more than protocol to check server responsiveness. You can specify that a server is available if it passes a single test in the list of tests or only if it passes all the tests.

To view the status currently detected by server health checks, use the Policy Status dashboard. For details, see Policy Status dashboard.

To configure a server health check

1. Before configuring a server health check, if it requires a trigger, configure the trigger. For details, see Viewing log messages.

2. Go to Server Objects > Server > Health Check.

To access this part of the web UI, your administrator’s account access profile must have Read and Write permission to items in the Server Policy Configuration category. For details, see Permissions.

3. Do one of the following:

To create a health check, click Create New.
To create a health check based on a predefined health check, select a predefined health check, click Clone, and then enter a name for the new health check.

4. Configure these settings:

Setting name	Description
Name	Type a unique name that can be referenced in other parts of the configuration. Do not use spaces or special characters. The maximum length is 63 characters. Note: The name cannot be changed after this part of the configuration is saved. To rename a part of the configuration, clone it, select it in all parts of the configuration that reference the old name, then delete the item with the old name.
Relationship	And — FortiWeb considers the server to be responsive when it passes all the tests in the list. Or — FortiWeb considers the server to be responsive when it passes at least one of the tests in the list.
Trigger Policy	Select the name of a trigger, if any, that will be used to log or notify an administrator if a server becomes unresponsive.

Setting name

Description

Name

Type a unique name that can be referenced in other parts of the configuration. Do not use spaces or special characters. The maximum length is 63 characters.

Note: The name cannot be changed after this part of the configuration is saved. To rename a part of the configuration, clone it, select it in all parts of the configuration that reference the old name, then delete the item with the old name.

Relationship

And — FortiWeb considers the server to be responsive when it passes all the tests in the list.
Or — FortiWeb considers the server to be responsive when it passes at least one of the tests in the list.

Trigger Policy

Select the name of a trigger, if any, that will be used to log or notify an administrator if a server becomes unresponsive.

5. Click OK.

6. In the rule list, do one of the following:

To add a rule, click Create New.
To modify a rule, select it, and then click Edit.

7. Configure the following settings:

Setting name	Description
Type	Select the protocol that the server health check uses to contact the server. ICMP — Send ICMP type 8 (`ECHO_REQUEST` or “ping”) and listen for either ICMP type 0 (`ECHO_RESPONSE` or “pong”) indicating responsiveness, or timeout indicating that the host is not responsive. TCP — Send TCP `SYN` and listen for either TCP `SYN ACK` indicating responsiveness, or timeout indicating that the host is not responsive. If the response is `SYN ACK`, send TCP `ACK` to complete the three-way handshake. TCP Half Open — Send TCP `SYN` and listen for either TCP `SYN ACK` indicating responsiveness, or timeout indicating that the host is not responsive. If the response is `SYN ACK`, send TCP `RST` to terminate the connection. This type of health check requires fewer resources from the pool member than TCP. TCP SSL — Send an HTTPS request. FortiWeb considers the host to be responsive if the SSL handshake is successful, and closes the connection once the handshake is complete. This type of health check requires fewer resources than HTTP/HTTPS. HTTP/HTTPS — Send an HTTP or HTTPS request, and listen for a response that matches the values required by the specified Matched Content or a timeout that indicates that the host is not responsive. The protocol to use depends on whether you enable SSL for that server in the server pool. Contact occurs on the protocol and port number specified for that web server in the server pool.
URL Path	Type the URL that the HTTP or HTTPS request uses to verify the responsiveness of the server (for example, `/index.html`). If the web server successfully returns this URL, and its content matches your expression in Matched Content, it is considered to be responsive. This option appears only if Type is HTTP or HTTPS. The maximum length is 127 characters.
Timeout	Type the maximum number of seconds that can pass after the server health check. If the web server exceeds this limit, it will indicate a failed health check. Valid values are 1 to 30. Default value is 3.
Retry Times	Type the number of times, if any, that FortiWeb retries a server health check after failure. If the web server fails the server health check this number of times consecutively, it is considered to be unresponsive. Valid values are 1 to 10. Default value is 3.
Interval	Type the number of seconds between each server health check. Valid values are 1 to 300. Default value is 10.
Method	Specify whether the health check uses the HEAD, GET, or POST method. Available only when Protocol Type is HTTP or HTTPS.
Host	To test the availability of a specific host, enter an HTTP host header name. This is useful if the pool member hosts multiple web sites (virtual hosting environment). This option appears only if Type is HTTP or HTTPS.
Match Type	Matched Content — If the web server successfully returns the URL specified by URL Path and its content matches the Matched Content value, FortiWeb considers the server to be responsive. Response Code — If the web server successfully returns the URL specified by URL Path and the code specified by Response Code, FortiWeb considers the server to be responsive. All — If the web server successfully returns the URL specified by URL Path and its content matches the Matched Content value, and the code specified by Response Code, FortiWeb considers the server to be responsive. Available only when Protocol Type is HTTP or HTTPS.
Matched Content	Enter one of the following values: The exact reply that indicates that the server is available. A regular expression that matches the required reply. This value prevents the test from falsely indicating that the server is available when it has actually replied with an error page, such as the one produced by Tomcat when a JSP application is not available. To create and test a regular expression, click the >> (test) icon. This opens a Regular Expression Validator window where you can fine-tune the expression (see Regular expression syntax) Available only if Protocol Type is HTTP or HTTPS and Match Type is All or Matched Content.
Response Code	Enter the response code that you require the server to return to confirm that it is available. Available only if Protocol Type is HTTP or HTTPS and Match Type is All or Matched Content.

8. Click OK to save the settings and close the rule.

9. Add any additional tests you want to include in the health check by adding additional rules.

10. Click OK to save and close the health check.

11. To use the server health check, select it in a server pool or server pool member configuration (see Creating a server pool).

Configuring session persistence

After FortiWeb has forwarded the first packet from a client to a pool member, some protocols require that subsequent packets also be forwarded to the same back-end server until a period of time passes or the client indicates that it has finished transmission.

A session persistence configuration specifies a persistence method and timeout. You apply the configuration to Server Balance server pools to apply the persistence setting to all members of the pool.

To create a persistence configuration

1. Go to Server Objects > Server > Persistence, and then click Create New.

2. Complete the following settings:

Setting name	Description
Name	Type a unique name that can be referenced in other parts of the configuration. Do not use spaces or special characters. The maximum length is 63 characters.
Type	Specifies how FortiWeb determines the pool member to forward subsequent requests from a client to after its initial request. For the initial request, FortiWeb selects a pool member using the load balancing method specified in the server pool configuration. Source IP — Forwards subsequent requests with the same client IP address and subnet as the initial request to the same pool member. To define how FortiWeb derives the appropriate subnet from the IP address, configure IPv4 Netmask and IPv6 Mask Length. HTTP Header — Forwards subsequent requests with the same value for an HTTP header as the initial request to the same pool member. Also configure Header Name. URL parameter — Forwards subsequent requests with the same value for a URL parameter as the initial request to the same pool member. Also configure Parameter Name. Insert Cookie — FortiWeb adds a cookie with the name specified by Cookie Name to the initial request and forwards all subsequent requests with this cookie to the same pool member. FortiWeb uses this cookie for persistence only and does not forward it to the pool member. Also configure Cookie Path and Cookie Domain. Rewrite Cookie — If the HTTP response has a `Set-Cookie:` value that matches the value specified by Cookie Name, FortiWeb replaces the value specified by the keyword with a randomly generated cookie value. FortiWeb forwards all subsequent requests with this generated cookie value to the same pool member. Persistent Cookie — If an initial request contains a cookie with a name that matches the Cookie Name value, FortiWeb forwards subsequent requests that contain the same cookie value to the same pool member as the initial request. Embedded Cookie — If the HTTP response contains a cookie with a name that matches the Cookie Name value, FortiWeb preserves the original cookie value and adds a randomly generated cookie value and a ~(tilde) as a prefix. FortiWeb forwards all subsequent requests with this cookie and prefix to the same pool member. ASP Session ID — If a cookie in the initial request contains an ASP .NET session ID value, FortiWeb forwards subsequent requests with the same session ID value to the same pool member as the initial request. (FortiWeb preserves the original cookie name.) PHP Session ID — If a cookie in the initial request contains a PHP session ID value, FortiWeb forwards subsequent requests with the same session ID value to the same pool member as the initial request. (FortiWeb preserves the original cookie name.) JSP Session ID — FortiWeb forwards subsequent requests with the same JSP session ID as the initial request to the same pool member. (FortiWeb preserves the original cookie name.) SSL Session ID — If a cookie in the initial request contains an SSL session ID value, FortiWeb forwards subsequent requests with the same session ID value to the same pool member as the initial request. (FortiWeb preserves the original cookie name.)
IPv4 Netmask	Specifies the IPv4 subnet used for session persistence. For example, if IPv4 Netmask is `255.255.255.255`, FortiWeb can forward requests from IP addresses 192.168.1.1 and 192.168.1.2 to different server pool members. If IPv4 Netmask is `255.255.255.0`, FortiWeb forwards requests from IP addresses 192.168.1.1 and 192.168.1.2 to the same pool member. Available only when Type is Source IP.
IPv6 Mask Length	Specifies the IPv6 network prefix used for session persistence. Available only when Type is Source IP.
Header Name	Specifies the name of the HTTP header that the persistence feature uses to route requests. Available only when Type is HTTP Header.
Parameter Name	Specifies the name of the URL parameter that the persistence feature uses to route requests. Available only when Type is URL Parameter.
Cookie Name	Specifies a value to match or the name of the cookie that FortiWeb inserts. Available only when the persistence type uses a cookie.
Cookie Path	Specifies a path attribute for the cookie that FortiWeb inserts, if Type is Insert Cookie.
Cookie Domain	Specifies a domain attribute for the cookie that FortiWeb inserts, if Type is Insert Cookie
Timeout	Specifies the maximum amount of time between requests that FortiWeb maintains persistence, in seconds. FortiWeb stops forwarding requests according to the established persistence after this amount of time has elapsed since it last received a request from the client with the associated property (for example, an IP address or cookie). Instead, it again selects a pool member using the load balancing method specified in the server pool configuration.

3. Click OK.

For information on applying the configuration to a pool, see Creating a server pool.

Configuring server-side SNI support

FortiWeb supports server-side SNI (Server Name Indication). You use this feature when you have the following configuration requirements:

The operating mode is reverse proxy or true transparent proxy.
You offload SSL/TLS processing to FortiWeb and use SSL/TLS for connections between FortiWeb and the pool member (end-to-end encryption).
One or more server pool members require SNI support.

In true transparent proxy mode, use the following CLI command to enable server-side SNI for the appropriate pool member:

config server-policy server-pool

edit <server-pool_name>

config pserver-list

edit <entry_index>

set server-side-sni {enable | disable}

In reverse proxy mode, use the following CLI command to enable server-side SNI in the appropriate server policy:

config server-policy policy

edit <policy_name>

set server-side-sni {enable | disable}

You cannot use the web UI to enable this option. For more information, see the FortiWeb CLI Reference.

Creating a server pool

Server pools define a group of one or more physical or domain servers (web servers) that FortiWeb distributes connections among, or where the connections pass through to, depending on the operating mode. (Reverse proxy mode actively distributes connections; offline protection mode, both transparent modes, and WCCP mode do not.)

Reverse proxy mode — When the FortiWeb appliance receives traffic destined for a virtual server, it forwards the traffic to a server pool. If the pool has more than one member, the physical or domain server that receives the connection depends on your configuration of load-balancing algorithm, weight, and server health checking.

For pools with multiple members, to prevent traffic from being forwarded to unavailable web servers, you can use a health check to verify the availability of members. The availability of other members and the Deployment Mode option in the policy determine whether the FortiWeb appliance redistributes or drops the connection when a physical or domain server in a server pool is unavailable.
Offline protection, true transparent proxy, transparent inspection, and WCCP mode — The FortiWeb appliance allows traffic to pass through to the server pool when it receives traffic that is:
- passing through a bridge
- directed to the FortiWeb (configured as a WCCP client) by a FortiGate acting as a WCCP server

A server can belong to more than one server pool.

To configure a server pool

1. Before you configure a server pool, do the following:

If clients connect via HTTPS and FortiWeb is operating in a mode that performs SSL inspection instead of SSL offloading, upload the web site’s server certificate. See Uploading a server certificate.
If you want to use the pool for load balancing and want to monitor its members for responsiveness, configure one or more server health checks to use with it. For details, see Configuring server up/down checks.
If client connections require persistent sessions, create a persistence configuration. See Configuring session persistence.

2. Go to Server Objects > Server > Server Pool.

3. Click Create New.

A dialog appears.

4. Configure these settings:

Setting name	Description
Name	Type a name that can be referenced by other parts of the configuration. Do not use spaces or special characters. The maximum length is 63 characters.
Type	Select the current operation mode of the appliance to display the corresponding pool options. For full information on the operating modes, see How to choose the operation mode.
Single Server/Server Balance	Single Server — Specifies a pool that contains a single member. Server Balance — Specifies a pool that contains multiple members. FortiWeb uses the specified load-balancing algorithm to distribute TCP connections among the members. If a member is unresponsive to the specified server health check, FortiWeb forwards subsequent connections to another member of the pool. Available only when Type is Reverse Proxy.
Server Health Check	Specifies a test for server availability. By default, this health check is used for all pool members, but you can use the pool member configuration to assign a different health check to a member. For more information, see Configuring server up/down checks. Available only when Type is Reverse Proxy and Single Server/Server Balance is Server Balance.
Load Balancing Algorithm	Round Robin — Distributes new TCP connections to the next pool member, regardless of weight, response time, traffic load, or number of existing connections. FortiWeb avoids unresponsive servers. Weighted Round Robin — Distributes new TCP connections using the round-robin method, except that members with a higher weight value receive a larger percentage of connections. Least Connection — Distributes new TCP connections to the member with the fewest number of existing, fully-formed TCP connections. URI Hash — Distributes new TCP connections using a hash algorithm based on the URI found in the HTTP header, excluding hostname. Full URI Hash — Distributes new TCP connections using a hash algorithm based on the full URI string found in the HTTP header. The full URI string includes the hostname and path. Host Hash — Distributes new TCP connections using a hash algorithm based on the hostname in the HTTP Request header Host field. Host Domain Hash — Distributes new TCP connections using a hash algorithm based on the domain name in the HTTP Request header Host field. Source IP Hash — Distributes new TCP connections using a hash algorithm based on the source IP address of the request. For hash-based methods, if you specify a persistence method for the server pool, after an initial client request, FortiWeb routes any subsequent requests according to the persistence method. Otherwise, it routes subsequent requests according to the hash-based algorithm. Available only when Type is Reverse Proxy and Single Server/Server Balance is Server Balance.
Persistence	Select a configuration that specifies a session persistence method and timeout to apply to the pool members. For more information, see Configuring session persistence.
Comments	Type a description of the server pool. The maximum length is 199 characters.

5. Click OK.

6. Click Create New.

A dialog appears.

7. Configure these settings:

Setting name	Description
ID	The index number of the member entry within the server pool. FortiWeb automatically assigns the next available index number. For round robin-style load-balancing, the index number indicates the order in which FortiWeb distributes connections. The valid range is from 0 to 9223372036854775807 (the maximum possible value for a long integer). You can use the `server-policy server-pool` CLI command to change the index number value. For more information, see the FortiWeb CLI Reference.
Status	Enable — Specifies that this pool member can receive new sessions from FortiWeb. Disable — Specifies that this pool member does not receive new sessions from FortiWeb and FortiWeb closes any current sessions as soon as possible. Maintenance — Specifies that this pool member does not receive new sessions from FortiWeb but FortiWeb maintains any current connections.
Server Type	Select either IP or Domain to indicate how you want to define the pool member.
IP or Domain	Specify the IP address or fully-qualified domain name of the web server to include in the pool. Tip: The IP or domain server is usually not the same as a protected host names group. See Protected web servers vs. allowed/protected host names. Warning: Server policies do not apply features that do not yet support IPv6 to servers specified using IPv6 addresses or domain servers whose DNS names resolve to IPv6 addresses. Tip: For domain servers, FortiWeb queries a DNS server to query and resolve each web server’s domain name to an IP address. For improved performance, do one of the following: use physical servers instead ensure highly reliable, low-latency service to a DNS server on your local network The Server Type value determines the name of this option.
Connection Limit	Specifies the maximum number of TCP connections that FortiWeb forwards to this pool member. The default is `0` (disabled). The valid range is from 0 to 1,048,576.
Port	Type the TCP port number where the pool member listens for connections. The valid range is from 1 to 65,535.
Weight	If the pool member is part of a pool that uses the weighted round-robin load-balancing algorithm, type the weight of the member when FortiWeb distributes TCP connections. Members with a greater weight receive a greater proportion of connections. Weighting members can be useful when, for example, some servers in the pool are more powerful or if a member is already receiving fewer or more connections due to its role in multiple web sites. This field appears only if the pool type is Server Balance.
Inherit Health Check	Clear to use the health check specified by Server Health Check in this server pool rule instead of the one specified in the server pool configuration.
Server Health Check	Specifies an availability test for this pool member. For more information, see Configuring server up/down checks.
Backup Server	When this option is selected and all the members of the server pool fail their server health check, FortiWeb routes any connections for the pool to this server. The backup server mechanism does not work if you do not specify server health checks for the pool members. If you select this option for more than one pool member, FortiWeb uses the load balancing algorithm to determine which member to use.
HTTP/2	Enable to allow HTTP/2 communication between the FortiWeb and this back-end web server. When FortiWeb's security services are applied to the HTTP/2 traffic between clients and this web server in Reverse Proxy mode: enabling this option makes sure the traffic is transferred in HTTP/2 between FortiWeb and this web server, if this web server supports HTTP/2. Note: Make sure that this back web server really supports HTTP/2 before you enable this, or connections will go failed. disabling this option makes FortiWeb to converse HTTP/2 to HTTP/1.x for this web server, or converse HTTP/1.x to HTTP/2 for the clients, if this web server does not support HTTP/2. In True Transparent Proxy mode, it requires this option be enabled and the SSL be well-configured to enable FortiWeb's HTTP/2 inspection. When HTTP/2 inspection is enabled in True Transparent Proxy mode, FortiWeb performs no protocol conversions between HTTP/1.x and HTTP/2, which means HTTP/2 connections will not be established between clients and back-end web servers if the web servers do not support HTTP/2. See HTTP/2 support for details. Note: Please confirm your FortiWeb operation mode and the HTTP versions your back-end web servers are running first to make appropriate configuration here, so that HTTP/2 inspection can work correctly with your web servers.
SSL	For reverse proxy, offline protection, and transparent inspection modes, specifies whether connections between FortiWeb and the pool member use SSL/TLS. For true transparent proxy and WCCP modes, specifies whether SSL/TLS processing is offloaded to FortiWeb and SSL/TLS is used for connections between FortiWeb and the pool member: For true transparent proxy mode, if the pool member requires SNI support, see Configuring server-side SNI support. For offline protection and transparent inspection modes, also configure Certificate File. FortiWeb uses the certificate to decrypt and scan connections before passing the encrypted traffic through to the pool members (SSL inspection). Note: Ephemeral (temporary key) Diffie-Hellman exchanges are not supported if the FortiWeb appliance is operating in transparent inspection or offline protection mode. For true transparent proxy and WCCP mode, also configure Certificate File, Client Certificate, and the settings described in step 8. FortiWeb handles SSL negotiations and encryption and decryption, instead of the pool member (SSL offloading). For reverse proxy mode You can configure SSL offloading for all members of a pool using a server policy. See Configuring a server policy. If the pool member requires SNI support, see Configuring server-side SNI support. Note: When this option is enabled, the pool member must be configured to apply SSL. Note: This option and related settings are required to be well-configured for enabling FortiWeb's HTTP/2 support in True Transparent Proxy mode.
Certificate File	Select the server certificate that FortiWeb uses to decrypt SSL-secured connections. For true transparent proxy and WCCP modes, also complete the settings described in described in step 8. Available when: SSL is enabled, and FortiWeb is operating in a mode other than reverse proxy, that performs SSL inspection. See Offloading vs. inspection.
Client Certificate	If connections to this pool member require a valid client certificate, select the client certificate that FortiWeb uses. Available when: SSL is enabled, and FortiWeb is operating in reverse proxy, true transparent proxy, or WCCP mode. Upload a client certificate for FortiWeb using the steps you use to upload a server certificate. See Uploading a server certificate.
Supported SSL Protocols	Specify which versions of the SSL or TLS cryptographic protocols clients can use to connect securely to this pool member. For more information, see Supported cipher suites & protocol versions. Available when: SSL is enabled, and FortiWeb is operating in reverse proxy, true transparent proxy, or WCCP mode.
SSL/TLS encryption level	Specify whether the set of cipher suites that FortiWeb allows creates a medium-security, high-security, or custom configuration. For more information, see Supported cipher suites & protocol versions. Available when: SSL is enabled, and FortiWeb is operating in reverse proxy, true transparent proxy, or WCCP mode.
Recover	Specifies the number of seconds that FortiWeb waits before it forwards traffic to this pool member after a health check indicates that this server is available again. The default is `0` (disabled). The valid range is 0 to 86,400 seconds. After the recovery period elapses, FortiWeb assigns connections at the rate specified by Warm Rate. Examples of when the server experiences a recovery and warm-up period: A server is coming back online after the health check monitor detected it was down. A network service is brought up before other daemons have finished initializing and therefore the server is using more CPU and memory resources than when startup is complete. To avoid connection problems, specify the separate warm-up rate, recovery rate, or both. Tip: During scheduled maintenance, you can also manually apply these limits by setting Status to Maintenance.
Warm Up	Specifies for how long FortiWeb forwards traffic at a reduced rate after a health check indicates that this pool member is available again but it cannot yet handle a full connection load. For example, when the pool member begins to respond but startup is not fully complete. The default is `0` (disabled). The valid range is 1 to 86,400 seconds.
Warm Rate	Specifies the maximum connection rate while the pool member is starting up. The default is `10` connections per second. The valid range is 0 to 86,400 connections per second. The warm up calibration is useful with servers that bring up the network service before other daemons are initialized. As these types of servers come online, CPU and memory are more utilized than they are during normal operation. For these servers, you define separate rates based on warm-up and recovery behavior. For example, if Warm Up is 5 and Warm Rate is 2, the maximum number of new connections increases at the following rate: 1st second — Total of 2 new connections allowed (0+2). 2nd second — 2 new connections added for a total of 4 new connections allowed (2+2). 3rd second — 2 new connections added for a total of 6 new connections allowed (4+2). 4th second — 2 new connections added for a total of 8 new connections allowed (6+2). 5th second — 2 new connections added for a total of 10 new connections allowed (8+2).

8. If the operating mode is transparent proxy or WCCP and SSL is enabled, complete the following additional settings to complete the SSL offloading configuration:

Setting name	Description
Certificate Intermediate Group	Select the name of a group of intermediate certificate authority (CA) certificates, if any, that FortiWeb presents to clients. An intermediate CA can complete the signing chain and validate the server certificate’s CA signature. Configure this option when clients receive certificate warnings that an intermediary CA has signed the server certificate specified by Certificate File, not a root CA or other CA currently trusted by the client directly. Alternatively, you can include the entire signing chain in the server certificate itself before you upload it to FortiWeb. See Uploading a server certificate and Supplementing a server certificate with its signing chain.
Show/Hide advanced SSL settings	Click to show or hide the settings that allow you to specify a Server Name Indication (SNI) configuration, increase security by disabling specific versions of TLS and SSL for this pool member, and other advanced SSL settings. For example, if FortiWeb can use a single certificate to decrypt and encrypt traffic for all the web sites that reside on the pool member, you may not have to set any advanced SSL settings. For more information, see the descriptions of the individual settings.
Add HSTS Header	Enable to combat MITM attacks on HTTP by injecting the RFC 6797 strict transport security header into the reply, such as: Strict-Transport-Security: max-age=31536000; includeSubDomains This header forces clients to use HTTPS for subsequent visits to this domain. If the certificate is invalid, the client’s web browser receives a fatal connection error and does not display a dialog that allows the user to override the certificate mismatch error and continue.
Certificate Verification	Select the name of a certificate verifier, if any, that FortiWeb uses to validate an HTTP client’s personal certificate. However, if you select Enable Server Name Indication (SNI) and the domain in the client request matches an entry in the specified SNI policy, FortiWeb uses the SNI configuration to determine which certificate verifier to use. If you do not select a verifier, clients are not required to present a personal certificate. See also How to apply PKI client authentication (personal certificates). Personal certificates, sometimes also called user certificates, establish the identity of the person connecting to the web site (PKI authentication). You can require that clients present a certificate instead of, or in addition to, HTTP authentication (see Offloading HTTP authentication & authorization). Note: The client must support SSL 3.0, TLS 1.0, TLS 1.1, or TLS 1.2. When the operating mode is reverse proxy, you can select this option in the server policy.
Enable URL Based Client Certificate	Specifies whether FortiWeb uses a URL-based client certificate group to determine whether a client is required to present a personal certificate. Note: This function is not supported for HTTP/2 communication between the Client and this back-end web server.
URL Based Client Certificate Group	Specifies the URL-based client certificate group that determines whether a client is required to present a personal certificate. If the URL the client requests does not match an entry in the group, the client is not required to present a personal certificate. For information on creating a group, see Use URLs to determine whether a client is required to present a certificate.
Max HTTP Request Length	Specifies the maximum allowed length for an HTTP request with a URL that matches an entry in the URL-based client certificate group. FortiWeb blocks any matching requests that exceed the specified size. This setting prevents a request from exceeding the maximum buffer size.
Client Certificate Forwarding	Enable to configure FortiWeb to include the X.509 personal certificate presented by the client during the SSL/TLS handshake, if any, in an `X-Client-Cert:` HTTP header when it forwards the traffic to the protected web server. FortiWeb still validates the client certificate itself, but this forwarding action can be useful if the web server requires the client certificate for the purpose of server-side identity-based functionality.
Enable Server Name Indication (SNI)	Select to use a Server Name Indication (SNI) configuration instead of or in addition to the server certificate specified by Certificate File. The SNI configuration enables FortiWeb to determine which certificate to present on behalf of the pool member based on the domain in the client request. See Allowing FortiWeb to support multiple server certificates. If you specify both an SNI configuration and Certificate File, FortiWeb uses the certificate specified by Certificate File when the domain in the client request does not match a value in the SNI configuration. If you select Enable Strict SNI, FortiWeb always ignores the value of Certificate File.
Enable Strict SNI	Select to configure FortiWeb to ignore the value of Certificate File when it determines which certificate to present on behalf of the pool member, even if the domain in a client request does not match a value in the SNI configuration. Available only if Enable Server Name Indication (SNI) is selected.
SNI Policy	Select the Server Name Indication (SNI) configuration that FortiWeb uses to determine which certificate it presents on behalf of this pool member. Available only if Enable Server Name Indication (SNI) is selected.
Enable Perfect Forward Secrecy	Enable to configure FortiWeb to generate a new public-private key pair when it establishes a secure session with a Diffie–Hellman key exchange. Perfect forward secrecy (PFS) improves security by ensuring that the key pair for a current session is unrelated to the key for any future sessions.
Prioritize RC4 Cipher Suite	Enable to configure FortiWeb to use the RC4 cipher when it first attempts to create a secure connection with a client. This option protects against a BEAST (Browser Exploit Against SSL/TLS) attack, a TLS 1.0 vulnerability. Enable only when: TLS 1.0 is enabled in SSL Protocols and SSL/TLS encryption level is either Medium or a custom encryption level that includes RC4-SHA or RC4-MD5.
Disable Client-Initiated SSL Renegotiation	Select to ignore requests from clients to renegotiate TLS or SSL. This setting protects against denial-of-service (DoS) attacks that use TLS/SSL renegotiation to overburden the server.

9. Repeat the previous steps for each IP address or domain that you want to add to the server pool.

10. Click OK.

11. To apply the server pool configuration, do one of the following:

Select it in a server policy directly.
Select it in an HTTP content writing policy that you can, in turn, select in a server policy.

See Configuring a server policy and Routing based on HTTP content.

Routing based on HTTP content

Instead of dynamically routing requests to a server pool simply based upon load or connection distribution at the TCP/IP layers, as basic load balancing does, you can forward them based on the host, headers or other content in the HTTP layer.

HTTP content routing policies define how FortiWeb routes requests to server pools. They are based on one or more of the following HTTP elements:

Host
URL
HTTP parameter
Referer
Source IP
Header
Cookie
X509 certificate field value

This type of routing can be useful if, for example, a specific web server or group of servers on the back end support specific web applications, functions, or host names. That is, your web servers or server pools are not identical, but specialized. For example:

192.168.0.1 — Hosts the web site and blog
192.168.0.2 and 192.168.0.3 — Host movie clips and multimedia
192.168.0.4 and 192.168.0.5— Host the shopping cart

Another example is a topology where back-end servers or a traffic controller (TC) server externally manage how FortiWeb routes and balances the traffic load. The TC embeds a cookie that indicates how to route the client’s next request. In the diagram, if a request has no cookie (that is, it initializes a session), FortiWeb’s HTTP content routing is configured to forward that request to the TC, Web Server 1. For subsequent requests, as long as the cookie exists, FortiWeb routes those requests to Web Server 2.

When FortiWeb operates in Reverse Proxy mode, HTTP Content Routing will be not supported if HTTP/2 security inspection (see HTTP/2 support) is enabled.

To configure HTTP header-based routing

1. Go to Server Objects > Server > HTTP Content Routing.

2. Click Create New.

3. For Name, enter a unique name that can be referenced in other parts of the configuration. Do not use spaces or special characters. The maximum length is 63 characters.

4. For Server Pool, select a server pool. FortiWeb forwards traffic to this pool when the traffic matches rules in this policy.

You select only one server pool for each HTTP content routing configuration. However, multiple HTTP content routing configurations can use the same server pool.

For more information, see Creating a server pool.

5. Click OK, then click Create New.

6. Configure these settings:

If you have configured request rewriting, configure HTTP content-based routing based on the original request, as it appears beforeFortiWeb has rewritten it.

For more information on rewriting, see Rewriting & redirecting.

Setting name		Description
Match Object		Select the object that FortiWeb examines for matching values.
HTTP Host
	HTTP Host
		Specify one of the following values to match: Match prefix — The host to match begins with the specified string. Match suffix — The host to match ends with the specified string. Match contains — The host to match contains the specified string. Match domain — The host to match contains the specified string between the periods in a domain name. For example, if the value is `abc`, the condition matches the following hostnames: `dname1.abc.com` `dname1.dname2.abc.com` However, the same value does not match the following hostnames: `abc.com` `dname.abc` Is equal to — The host to match is the specified string. Regular expression — The host to match has a value that matches the specified regular expression.
	(value)	Specifies a host value to match. If Regular Expression is selected, the value is an expression that matches the object. To create and test a regular expression, click the >> (test) icon (see Regular expression syntax).
	Relationship with previous rule	And — Matching requests match this entry in addition to other entries in the HTTP content routing list. Or — Matching requests match either this entry or other entries in the list. Later, you can use the HTTP content routing list options to adjust the matching sequence for entries.
HTTP URL
	HTTP URL	Specify one of the following values to match: Match prefix — The URL to match begins with the specified string. Match suffix — The URL to match ends with the specified string. Match contains — The URL to match contains the specified string. Match directory — The URL to match contains the specified string between delimiting characters (slash). For example, if the value is `abc`, the condition matches the following URLs: `test.com/abc/` `test.com/dir1/abc/` However, the same value does not match the following URLs: `test.com/abc` `test.abc.com` Is equal to — The URL to match is the specified string. Regular expression — The URL to match matches the specified regular expression.
	(value)	Specifies a URL to match. For example, a literal URL, such as `/index.php`, that a matching HTTP request contains. For example, when Is equal to is selected, the value `/dir1/abc/index.html` matches the following URL: `http://test.abc.com/dir1/abc/index.html` If Regular Expression is selected, the value is an expression that matches the object. For example, `^/*.php`. To create and test a regular expression, click the >> (test) icon (see Regular expression syntax).
	Relationship with previous rule	And — Matching requests match this entry in addition to other entries in the HTTP content routing list. Or — Matching requests match either this entry or other entries in the list. Later, you can use the HTTP content routing list options to adjust the matching sequence for entries.
HTTP Parameter
	Parameter Name	Specify one of the following values to match: Match prefix — The parameter name to match begins with the specified string. Match suffix — The parameter name to match ends with the specified string. Match contains — The parameter name to match contains the specified string. Is equal to — The parameter name to match is the specified string. Regular expression — The parameter name to match matches the specified regular expression.
	(value)	Specifies a parameter name to match. If Regular Expression is selected, the value is an expression that matches the object. To create and test a regular expression, click the >> (test) icon (see Regular expression syntax).
	Parameter Value	Specify one of the following values to match: Match prefix — The parameter value to match begins with the specified string. Match suffix — The parameter value to match ends with the specified string. Match contains — The parameter value to match contains the specified string. Is equal to — The parameter value to match is the specified string. Regular expression — The parameter value to match matches the specified regular expression.
	(value)	Specifies a parameter value to match. If Regular Expression is selected, the value is an expression that matches the object. To create and test a regular expression, click the >> (test) icon (see Regular expression syntax).
	Relationship with previous rule	And — Matching requests match this entry in addition to other entries in the HTTP content routing list. Or — Matching requests match this entry or other entries in the list. Later, you can use the HTTP content routing list options to adjust the matching sequence for entries.
HTTP Referer
	HTTP Referer	Specify one of the following values to match: Match prefix — The HTTP referer value to match begins with the specified string. Match suffix — The HTTP referer value to match ends with the specified string. Match contains — The HTTP referer value to match contains the specified string. Is equal to — The HTTP referer value to match is the specified string. Regular expression — The HTTP referer value to match matches the specified regular expression.
	(value)	Specifies an HTTP referer value to match. If Regular Expression is selected, the value is an expression that matches the HTTP referer value. To create and test a regular expression, click the >> (test) icon (see Regular expression syntax).
	Relationship with previous rule	And — Matching requests match this entry in addition to other entries in the HTTP content routing list. Or — Matching requests match this entry or other entries in the list. Later, you can use the HTTP content routing list options to adjust the matching sequence for entries.
HTTP Cookie
	HTTP Cookie	Specify one of the following values to match: Match prefix — The cookie name to match begins with the specified string. Match suffix — The cookie name to match ends with the specified string. Match contains — The cookie name to match contains the specified string. Is equal to — The cookie name to match is the specified string. Regular expression — The cookie name to match matches the specified regular expression.
	(value)	Specifies a cookie name to match. If Regular Expression is selected, the value is an expression that matches the name. To create and test a regular expression, click the >> (test) icon (see Regular expression syntax).
	Cookie Value	Specify one of the following values to match: Match prefix — The cookie value to match begins with the specified string. Match suffix — The cookie value to match ends with the specified string. Match contains — The cookie value to match contains the specified string. Is equal to — The cookie value to match is the specified string. Regular expression — The cookie value to match matches the specified regular expression. For example, `hash[a-fA-F0-7]*.`
	(value)	Specifies a cookie value to match. If Regular Expression is selected, the value is an expression that matches the cookie value. To create and test a regular expression, click the >> (test) icon (see Regular expression syntax).
	Relationship with previous rule	And — Matching requests match this entry in addition to other entries in the HTTP content routing list. Or —Matching requests match either this entry or other entries in the list. Later, you can use the HTTP content routing list options to adjust the matching sequence for entries.
HTTP Header
	Header Name	Specify one of the following values to match: Match prefix — The header name to match begins with the specified string. Match suffix — The header name to match ends with the specified string. Match contains — The header name to match contains the specified string. Is equal to — The header name to match is the specified string. Regular expression — The header name to match matches the specified regular expression.
	(value)	Specifies a header name to match. If Regular Expression is selected, the value is an expression that matches the name. To create and test a regular expression, click the >> (test) icon (see Regular expression syntax).
	Header Value	Specify one of the following values to match: Match prefix — The header value to match begins with the specified string. Match suffix — The header value to match ends with the specified string. Match contains — The header value to match contains the specified string. Is equal to — The header value to match is the specified string. Regular expression — The header value to match matches the specified regular expression.
	(value)	Specifies a header value to match. If Regular Expression is selected, the value is an expression that matches the header value. To create and test a regular expression, click the >> (test) icon (see Regular expression syntax).
	Relationship with previous rule	And — Matching requests match this entry in addition to other entries in the HTTP content routing list. Or —Matching requests match this entry or other entries in the list. Later, you can use the HTTP content routing list options to adjust the matching sequence for entries.
Source IP
	Source IP	Specify one of the following values to match: IPv4 Address/Range — The source IP to match is an IPv4 IP address or within a range of IPv4 IP addresses. IPv6 Address/Range — The source IP to match is an IPv6 IP address or within a range of IPv6 IP addresses. Regular expression — The source IP to match matches the specified regular expression.
	(value)	Specifies a source IP address value to match. If Regular Expression is selected, the value is an expression that matches the source IP. To create and test a regular expression, click the >> (test) icon (see Regular expression syntax).
	Relationship with previous rule	And — Matching requests match this entry in addition to other entries in the HTTP content routing list. Or — Matching requests match either this entry or other entries in the list. Later, you can use the HTTP content routing list options to adjust the matching sequence for entries.
X509 Certificate Subject		Matches against a specified Relative Distinguished Name (RDN) in the X509 certificate `Subject` field. Use an attribute-value pair to specify the RDN. For example, an X509 certificate has the following `Subject` field content: C=CN, ST=Beijing, L=Haidian, O=fortinet, OU=fortiweb, CN=pc110 The following settings match a certificate with this `Subject` field by matching the RDN `O=fortinet`: X509 Field Name — O Value = — `fortinet`
	X509 Field Name	Select the attribute type to match: E, CN, OU, O, L, ST, C.
	Value =	Enter an RDN attribute value in the X509 `Subject` field to match.
	Relationship with previous rule	And — Matching requests match this entry in addition to other entries in the HTTP content routing list. Or —Matching requests match either this entry or other entries in the list. Later, you can use the HTTP content routing list options to adjust the matching sequence for entries.
X509 Certificate Extension		Matches against additional fields that the extensions field adds to the X509 certificate. For example, an X509 certificate has the following extensions: Extensions: X509v3 Basic Constraints: CA:TRUE X509v3 Subject Alternative Name: URI:aaaa X509v3 Issuer Alternative Name: URI:bbbb Full Name: URI:cccc The following settings match the extension X509v3 Basic Constraints by matching its value: Match Object — X509 Certificate Extension X509 Field Value — Is equal to (value) — `CA:TRUE`
	X509 Field Value	Specify one of the following values in the X509 extension to match: Match prefix — The X509 extension value to match begins with the specified string. Match suffix — The X509 extension value to match ends with the specified string. Match contains — The X509 extension value to match contains the specified string. Is equal to — The X509 extension value to match is the specified string. Regular expression — The X509 extension value matches the specified regular expression.
	(value)	Specifies an X509 extension value to match. If Regular Expression is selected, the value is an expression that matches the X509 extension value. To create and test a regular expression, click the >> (test) icon (see Regular expression syntax).
	Relationship with previous rule	And — Matching requests match this entry in addition to other entries in the HTTP content routing list. Or —Matching requests match either this entry or other entries in the list. Later, you can use the HTTP content routing list options to adjust the matching sequence for entries.

7. Click OK.

8. Repeat the rule creation steps for each HTTP host, HTTP request, or other object that you want to route to this server pool.

9. If required, select an entry, and then click Move to adjust the rule sequence.

For an example of how to add logic for the rules, see Example: Concatenating exceptions.

10. Click OK.

11. Repeat the policy creation procedure for each server pool, as required. You can also create additional policies that select the same server pool.

12. To apply a HTTP content routing policy, select it in a server policy. When you add HTTP content routing polices to a policy, you also select a default policy. The default policy routes traffic that does not match any conditions found in the specified routing policies.

For more information, see Configuring a server policy.

Example: Routing according to URL/path

Your FortiWeb appliance might have one virtual server (the front end) protecting three physical web servers (the back end).

From the perspective of clients connecting to the front end, there is one domain name: www.example.com. At this host name, there are three top-level URLs:

/games — Game application
/school — School application
/work — Work application

In a client’s web browser, therefore, they might go to the location:

http://www.example.com/games

Behind the FortiWeb, however, each of those 3 web applications actually resides on separate back-end web servers with different IP addresses, and each has its own server pool:

10.0.0.11/games — Game application
10.0.0.12/school — School application
10.0.0.13/work — Work application

In this case, you configure HTTP content routing so FortiWeb routes HTTP requests to http://www.example.com/school to the server pool that contains 10.0.0.12. Similarly, requests for the URL /games go to a pool that contains 10.0.0.11, and requests for the URL /work go to a pool that contains 10.0.0.13.

Example: Routing according to the HTTP “Host:” field

Your FortiWeb appliance might have one virtual server (the front end) protecting three physical web servers (the back end).

From the perspective of clients connecting to the front end, Example Company’s web site has a few domain names:

http://www.example.com
http://www.example.cn
http://www.example.de
http://www.example.co.jp

Public DNS resolves all of these domain names to one IP address: the virtual server on FortiWeb.

At the data center, behind the FortiWeb, separate physical web servers host some region-specific web sites. Other web sites have lighter traffic and are maintained by the same person, and therefore a shared server hosts them. Each back-end web server has a DNS alias. When you configure the server pools, you define each pool member using its DNS alias, rather than its IP address:

www1.example.com — Hosts www.example.com, plus all other host names’ content, in case the other web servers fail or have scheduled down time
www2.example.com — Hosts www.example.de
www3.example.com — Hosts www.example.cn & www.example.co.jp

While public DNS servers all resolve these aliases to the same IP address — FortiWeb’s virtual server — your private DNS server resolves these DNS names to separate IPs on your private network: the back-end web servers.

www1.example.com — Resolves to 192.168.0.1
www2.example.com — Resolves to 192.168.0.2
www3.example.com — Resolves to 192.168.0.3

In this case, you configure HTTP content routing to route requests from clients based on the original Host: field in the HTTP header to a server pool that contains the appropriate DNS aliases. The destination back-end web server is determined at request time using server health check statuses, as well as private network DNS that resolves the DNS alias into its current private network IP address:

http://www.example.com/ — Routes to a pool that contains www1.example.com
http://www.example.de/ — Routes to a pool that contains members www2.example.com and www1.example.com. The www2.example.com pool member is first in the list and receives requests unless that web server is down, in which case FortiWeb routes requests to www1.example.com
http://www.example.cn/ & http://www.example.co.jp/ — Routes to a pool that contains members www3.example.com and www1.example.com. The www3.example.com pool member is first in the list and receives requests unless that web server is down, in which case FortiWeb routes requests to www1.example.com

If you need to maintain HTTP session continuity for web applications, ensure the pool have a persistence policy that forwards subsequent requests from a client to the same back-end web server as the initial request.

Example: HTTP routing with full URL & host name rewriting

In some cases, HTTP header-based routing is not enough. It must be, or should be, combined with request or response rewriting.

Example.com hosts calendar, inventory, and customer relations management web applications separately: one app per specialized server. Each web application resides in its web server’s root folder ( / ). Each back-end web server is named after the only web application that it hosts:

calendar.example.com/
inventory.example.com/
crm.example.com/

Therefore each request must be routed to a specific back-end web server. Requests for the calendar application forwarded to crm.example.com, for example, would result in an HTTP 404 error code.

These back-end DNS names are publicly resolvable. However, for legacy reasons, clients may request pages as if all apps were hosted on a single domain, www.example.com:

www.example.com/calendar
www.example.com/inventory
www.example.com/crm

Because the URLs requested by clients (prefixed by /calendar etc.) do not actually exist on the back-end servers, HTTP header-based routing is not enough. Alone, HTTP header-based routing with these older location structures would also result in HTTP 404 error codes, as if the clients’ requests were effectively for:

calendar.example.com/calendar
inventory.example.com/inventory
crm.example.com/crm

To compensate for the new structure on the back end, request URLs must be rewritten: FortiWeb removes the application name prefix in the URL.

URL and host name transformation to match HTTP routing

For performance reasons, FortiWeb also rewrites the Host: field. All subsequent requests from the client use the correct host and URL and do not require any modification or HTTP-based routing. Otherwise, FortiWeb would need to rewrite every subsequent request in the session, and analyze the HTTP headers for routing every subsequent request in the session.