Defining your web servers

You are here: Defining your web servers & load balancers > Defining your web servers

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 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. Server health checks can use TCP, HTTP/HTTPS, or ICMP ECHO_REQUEST (ping).

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 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 35 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 35 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
Protocol Type	Select the protocol that the server health check uses to contact the server. Ping — 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. 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 Protocol 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.
Match Type	Matched Content — If the web server successfully returns the URL specified by URL Path and its content matches the Matched Content value, FortiWebconsiders 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, FortiWebconsiders 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, FortiWebconsiders 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.

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 which pool member to forward subsequent requests from a client after it has forwarded the client’s initial request. For the initial request, FortiWeb selects a pool member using the load balancing method specified in the server pool configuration. Persistent IP — FortiWeb forwards subsequent requests with the same client IP address as the initial request to the same pool member. Persistent Cookie — If an initial request contains a cookie whose name matches the Cookie Name value, FortiWeb forwards subsequent requests that contain the same cookie value to the same pool member as the initial request. Insert Cookie — FortiWeb inserts a cookie with the name `cookiesession2` to the in it al 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. 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.)
Cookie Name	When the value of Type is Persistent Cookie, specifies the cookie name to match in an initial request from a client. If the cookie name in the initial request matches Persistent Cookie, FortiWeb forwards any subsequent requests with that cookie value the same pool member as the initial request.
Persistence 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 session persistence per transaction

When FortiWeb maintains session persistence using cookies (Persistent Cookie, Insert Cookie), it tracks or inserts the cookie for the first transaction of a session only. It does not track or insert a cookie in subsequent transactions in the session, even if the transaction does not contain a control cookie.

This method maintains session persistence in most environments. However, it does not work if your environment uses TCP multiplexing, which combines HTTP requests from multiple clients in a single session for load balancing or other purposes.

To avoid this problem, use the following CLI command to configure the cookie-based session persistence feature to track or insert a control cookie for each transaction in a TCP session that does not already have a control cookie:

config server-policy policy

edit <policy_name>

set sessioncookie-enforce enable

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

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 and both transparent modes 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, and transparent inspection mode — When the FortiWeb appliance receives traffic destined for a virtual server or passing through a bridge, it allows the traffic to pass through to the server pool.

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. 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 63 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 65,535. 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.
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 Type is Server Balance.
Inherit Health Check	Clear to use the health check specified by Server Health Check 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.
SSL	For reverse proxy, offline protection, and transparent inspection modes, enable to use SSL/TLS for connections between FortiWeb and the pool member. For true transparent proxy: Enable to both offload SSL/TLS processing to FortiWeb and use SSL/TLS for connections between FortiWeb and the pool member. 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, 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.
Certificate File	Do one of the following: Select the server certificate that FortiWeb uses to decrypt SSL-secured connections. Select Create New to open a window that allows you to upload a new certificate. For more information, see Uploading a server certificate. For true transparent proxy operating mode, 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 or true transparent proxy mode. Upload a client certificate for FortiWeb using the steps you use to upload a server certificate. See Uploading a server certificate.
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 Type is Server Balance.

8. If the operating mode is transparent proxy 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.
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.
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.
SSL/TLS encryption level	Specify whether the set of cipher suites that FortiWeb allows creates a medium-security or high-security configuration. For more information, see Supported cipher suites & protocol versions.
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 Medium.
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 header content, source IP, or cookie.

Routing based on HTTP header content, source IP, or cookie

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 headers in the HTTP layer.

HTTP header-based routes (called “HTTP content routing policies” in the web UI) define how FortiWeb routes requests to server pools. They are based on one or more of the following HTTP header elements:

Host
HTTP Request
Referer
Source IP
cookie

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

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 one of the following as the object that FortiWeb examines for matching values: HTTP Host — `Host:` field HTTP Request — Request URL HTTP Referer — `Referer:` field Source IP — Source IP address of request HTTP Request Cookie
Match Condition	Specifies whether the value to match is a literal value that appears in the object or a regular expression. The value of Match Object determines which content types you can select. For HTTP Host, HTTP Request, and HTTP Referer only: Match prefix — The object to match begins with the specified string. Match suffix — The object to match ends with the specified string. Match contains — The object to match contains the specified string. For HTTP Host only: Match domain — The object to match contains the specified string between the periods in a domain name. For example, if Match Simple String is `abc`, the condition matches the following hostnames: `dname1.abc.com` `dname1.dname2.abc.com` However, the same Match Simple String value does not match the following hostnames: `abc.com` `dname.abc` For HTTP Request, and HTTP Referer only: Match directory — The object to match contains the specified string between delimiting characters (slash) in a domain name. For example, if Match Simple String is `abc`, the condition matches the following hostnames: `test.com/abc/` `test.com/dir1/abc/` `http://test.abc.com/` However, the same Match Simple String value does not match the following hostnames: `test.com/abc` `test.abc.com` For all object types: Regular expression — The object to match has a value that matches the specified regular expression.
Match Simple String	Specifies a value to match in the object element specified by Match Object and Match Condition. Displayed when the condition to match is a prefix, suffix, part of the domain name, or other literal object value. For example, a literal URL, such as `/index.php`, that a matching HTTP request contains.
Regular Expression	Specifies a regular expression to match a value in the object element specified by Match Object and Match Condition. Displayed when the value of Match Condition is Regular Expression. For example, an expression, such as `^/.php`, that matches a URL. To create and test a regular expression, click the >> (test) icon. This opens the Regular Expression Validator* window where you can fine-tune the expression (see Regular expression syntax).
Cookie Name	Enter a regular expression to match the name of the cookie that appears in an HTTP header. For example, the name of a cookie embedded by traffic controller software on one of the servers. Displayed when Match Object is HTTP Request Cookie. To create and test a regular expression, click the >> (test) icon. This opens the Regular Expression Validator window where you can fine-tune the expression (see Regular expression syntax).
Cookie Value	Enter a regular expression that matches all and only the cookie values you want the rule to apply to. For example, `hash[a-fA-F0-7].` To create and test a regular expression, click the >> (test) icon. This opens the Regular Expression Validator* window where you can fine-tune the expression (see Regular expression syntax).

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

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

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