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