HTTP and HTTPS load balancing, multiplexing, and persistence
In a firewall load balancing virtual server configuration, you can select HTTP to load balance only HTTP sessions. The virtual server will load balance HTTP sessions received at the virtual server interface with destination IP address that matches the configured virtual server IP and destination port number that matches the configured virtual server port. The default virtual server port for HTTP load balancing is 80, but you can change this to any port number. Similarly for HTTPS load balancing, set the virtual server type to HTTPS and then select the interface, virtual server IP, and virtual server port that matches the HTTPS traffic to be load balanced. Usually HTTPS traffic uses port 443.
You can also configure load balancing to offload SSL processing for HTTPS and SSL traffic.
HTTP and HTTPS multiplexing
For both HTTP and HTTPS load balancing you can multiplex HTTP requests and responses over a single TCP connection. HTTP multiplexing is a performance saving feature of HTTP/1.1 compliant web servers that provides the ability to pipeline many unrelated HTTP or HTTPS requests on the same connection. This allows a single HTTPD process on the server to interleave and serve multiple requests. The result is fewer idle sessions on the web server so server resources are used more efficiently. HTTP multiplexing can take multiple separate inbound sessions and multiplex them over the same internal session. This may reduce the load on the backend server and increase the overall performance.
HTTP multiplexing may improve performance in some cases. For example, if users web browsers are only compatible with HTTP 1.0. HTTP multiplexing can also improve performance between a web server and the FortiGate unit if the FortiGate unit is performing SSL acceleration. However, in most cases HTTP multiplexing should only be used if enabling it leads to a measurable improvement in performance.
To enable HTTP multiplexing from the web-based manager, select multiplex HTTP requests/responses over a single TCP connection. To enable HTTP multiplexing from the CLI enable the http-multiplex option.
Preserving the client IP address
Select preserve client IP from the web-based manager or enable the http-ip-header option from the CLI to preserve the IP address of the client in the X-Forwarded-For HTTP header. This can be useful in an HTTP multiplexing configuration if you want log messages on the real servers to the client’s original IP address. If this option is not selected, the header will contain the IP address of the FortiGate unit.
Preserving the client IP address but changing the X-Forwarded-For header name
If you select preserve client IP from the web-based manager or enable the http-ip-header option from the CLI you can also change the name of the X-Forwarded-For header to a custom header name. This can be useful if you want to use a custom header name instead of the standard header name.
You can configure changing the header name from the CLI. When http-ip-header is enabled you can add a custom header name to the http-ip-header-name option. If you don’t add a custom header name the X- Forwarded-For header name is maintained.
HTTP and HTTPS persistence
Configure load balancing persistence for HTTP or HTTPS to make sure that a user is connected to the same server every time they make a request that is part of the same session. HTTP cookie persistence uses injected cookies to enable persistence.
When you configure persistence, the FortiGate unit load balances a new session to a real server according to the Load Balance Method. If the session has an HTTP cookie or an SSL session ID, the FortiGate unit sends all subsequent sessions with the same HTTP cookie or SSL session ID to the same real server.
The following example shows how to enable cookie persistence and set the cookie domain to .example.org.
config firewall vip
edit HTTP_Load_Balance
set type server-load-balance set server-type http
set extport 8080 set extintf port2
set extip 192.168.20.20
set persistence http-cookie
set http-cookie-domain .example.org config realservers
edit 1
set ip 10.10.10.1 set port 80
next
edit 2
set ip 10.10.10.2 set port 80
next edit 3
set ip 10.10.10.3 set port 80
end
How HTTP cookie persistence options work
The following options are available for the config firewall vip command when type is set to server- load-balance, server-type is set to http or https and persistence is set to http-cookie:
http-cookie-domain-from-host http-cookie-domain
http-cookie-path
http-cookie-generation http-cookie-age
http-cookie-share https-cookie-share
When HTTP cookie persistence is enabled the FortiGate unit inserts a header of the following form into each
HTTP response unless the corresponding HTTP request already contains a FGTServer cookie:
Set-Cookie: FGTServer=E7D01637C4B08E89A6714213A9D85D9C7E4D8158; Version=1; Max-Age=3600
The value of the FGTServer cookie encodes the server that traffic should be directed to. The value is encoded so as to not leak information about the internal network.
Enable http-cookie-domain-from-host to extract the cookie domain from the host: header in the HTTP request. For example, to restrict the cookie to.server.com, enter:
The generated cookies could have the following form if the Host: header contains exhost.com:
Set-Cookie: FGTServer=E7D01637C4B08E89A6714213A9D85D9C7E4D8158; Version=1; Domain=.exhost.com; Max-Age=3600
For more information, see “HTTP host-based load balancing”.
Use http-cookie-domain to restrict the domain that the cookie should apply to. For example, to restrict the cookie to.server.com, enter:
set http-cookie-domain .server.com
Now all generated cookies will have the following form:
Set-Cookie: FGTServer=E7D01637C4B08E89A6714213A9D85D9C7E4D8158; Version=1; Domain=.server.com; Max-Age=3600
Use http-cookie-path to limit the cookies to a particular path. For example, to limit cookies to the path /sales, enter:
set http-cookie-path /sales
Now all generated cookies will have the following form:
Set-Cookie: FGTServer=E7D01637C4B08E89A6714213A9D85D9C7E4D8158; Version=1; Domain=.server.com; Path=/sales; Max-Age=3600
Use http-cookie-age to change how long the browser caches the cookie. You can enter an age in minutes or set the age to 0 to make the browser keep the cookie indefinitely:
set http-cookie-age 0
Now all generated cookies will have the following form:
Set-Cookie: FGTServer=E7D01637C4B08E89A6714213A9D85D9C7E4D8158; Version=1; Domain=.server.com; Path=/sales
Use http-cookie-generation to invalidate all cookies that have already been generated. The exact value of the generation is not important, only that it is different from any generation that has already been used for cookies in this domain. The simplest approach is to increment the generation by one each time invalidation is required. Since the default is 0, enter the following to invalidate all existing cookies:
set http-cookie-generation 1
Use http-cookie-share {disable | same-ip} to control the sharing of cookies across virtual servers in the same virtual domain. The default setting same-ip means that any FGTServer cookie generated by one virtual server can be used by another virtual server in the same virtual domain. For example, if you have an application that starts on HTTP and then changes to HTTPS and you want to make sure that the same server is used for the HTTP and HTTPS traffic then you can create two virtual servers, one for port 80 (for HTTP) and one for port 443 (for HTTPS). As long as you add the same real servers to both of these virtual servers (and as long as both virtual servers have the same number of real servers with the same IP addresses), then cookies generated by accessing the HTTP server are reused when the application changes to the HTTPS server.
If for any reason you do not want this sharing to occur then select disable to make sure that a cookie generated for a virtual server cannot be used by other virtual servers.
Use https-cookie-secure to enable or disable using secure cookies. Secure cookies are disabled by default because secure cookies can interfere with cookie sharing across HTTP and HTTPS virtual servers. If enabled, then the Secure tag is added to the cookie inserted by the FortiGate unit:
Set-Cookie: FGTServer=E7D01637C4B08E89A6714213A9D85D9C7E4D8158; Version=1; Max-Age=3600; Secure
HTTP host-based load balancing
When configuring HTTP or HTTPS load balancing you can select HTTP host load balancing to load balances HTTP host connections across multiple real servers using the host’s HTTP header to guide the connection to the correct real server. HTTP 1.1 includes the concept of a virtual server which allows a HTTP or HTTPS server with a single external IP address to serve requests for multiple DNS domains by using the mandatory Host: header in a HTTP request to indicate which DNS domain the request is destined for.
FortiOS can load-balance HTTP and HTTPS connections among multiple real servers using the Host: header to guide the connection to the correct real server. The host load balancing method allows a real server to specify a http-host attribute which is the domain name of the traffic for that real server. Each real server can only specify a single domain name. The same domain name can appear in more than one real server but only the first one that is up will be used, any others are purely for redundancy. If the Host: header contains a domain that does not match any http-host entry then the connection will be dropped. A real server with no http-host can be matched by any Host: domain.
For example, consider a FortiGate unit that is load-balancing traffic to three real servers. Traffic for www.example1.com should go to 192.168.2.1, traffic for www.example2.com should go to 192.168.2.2 and traffic to any other domain should go to 192.168.2.3. To enable this configuration you would add a virtual server and set the load balance method to HTTP host. Then you would add three real servers and set the HTTP host of the real server with IP address 192.168.2.1 to www.example1.com, the HTTP host of the real server with IP address 192.168.2.2 to www.example2.com and you would not specify an HTTP host for the third real server.
The configuration of a virtual IP to achieve this result would be:
config firewall vip
edit “http-host-ldb”
set type server-load-balance set extip 172.16.67.195
set extintf “lan”
set server-type http
set ldb-method http-host set extport 80
config realservers edit 1
set http-host “www.example1.com” set ip 192.168.2.1
set port 80
next edit 2
set http-host “www.example2.com” set ip 192.168.2.2
set port 80
next edit 3
set ip 192.168.2.3 set port 80
end
next end
Host load balancing and HTTP cookie persistence
In an HTTP host-based load balancing configuration with HTTP cookie persistence enabled you can optionally configure cookie persistence to use the domain set in the host header as the cookie domain. You can do this by enabling the http-cookie-domain-from-host option, for example:
config firewall vip
edit “http-host-ldb”
set type server-load-balance set extip 172.16.67.195
set extintf “lan”
set server-type http
set ldb-method http-host set extport 80
set persistence http-cookie
set http-cookie-domain-from-host enable config realservers
edit 1
set http-host “www.example1.com” set ip 192.168.2.1
set port 80 next
edit 2
set http-host “www.example2.com” set ip 192.168.2.2
set port 80 next
edit 3
set ip 192.168.2.3
end
set port 80 next
end