Fortinet Document Library

Version:

Version:


Table of Contents

Handbook

Download PDF
Copy Link

Configuring persistence rules

Persistence rules identify traffic that should not be load balanced, but instead forwarded to the same backend server that has seen requests from that source before. Typically, you configure persistence rules to support server transactions that depend on an established client-server session, like e-commerce transactions or SIP voice calls.

The system maintains persistence session tables to map client traffic to backend servers based on the session attribute specified by the persistence rule.

The persistence table is evaluated before load balancing rules. If the packets received by the ADC match an entry in the persistence session table, the packets are forwarded to the server that established the connection, and load balancing rules are not applicable.

Most persistence rule types have a timeout. When the time that has elapsed since the system last received a request from the client IP address is greater than the timeout, the system does not use the mapping table to forward the request. Instead, it again selects the server using the method specified in the virtual server configuration. Hash-based rule types have a timeout built into the hash algorithm. For other types, you can specify the timeout.

Predefined persistence rules describes the predefined persistence rules. You can get started with these commonly used persistence methods or create custom objects.

Predefined persistence rules

Predefined Description

LB_PERSIS_SIP

Persistence based on source IP address or subnet.

LB_PERSIS_CONSISTENT_SIP

Persistence based on a hash of source IP address.

LB_PERSIS_HASH_SRC_ADDR_PORT

Persistence based on a hash that includes source IP address and port.

LB_PERSIS_HASH_COOKIE

Persistence based on a hash of a session cookie provided by the backend server.

LB_PERSIS_RDP_COOKIE

Persistence based on RDP cookie sent by RDP clients in the initial connection request.

LB_PERSIS_SSL_SESS_ID

Persistence based on the SSL session ID.

LB_PERSIS_SIP_CALL_ID

Persistence based on the SIP call ID.

LB_PERSIS_PASSIVE_COOKIE

Persistence based on a passive cookie generated by the server. FortiADC does not generate or manage the cookie, but only observes it in the HTTP stream, thus the name "passive cookie". Also known as "server cookie".

Before you begin:

  • You must have a good understanding and knowledge of the applications that require persistent sessions and the methods that can be used to identify application sessions.
  • You must have Read-Write permission for Load Balance settings.

After you have configured a persistence rule, you can select it in the virtual server configuration.

To configure a persistence rule:
  1. Go to Server Load Balance > Application Resources.
  2. Click the Persistence tab.
  3. Click Create New to display the configuration editor.
  4. Give the rule a name, select the type, and specify rule settings as described in Persistence rule guidelines.
  5. Save the configuration.

 

You can clone a predefined configuration object to help you get started with a user-defined configuration.

To clone a configuration object, click the clone icon that appears in the tools column on the configuration summary page.

 

Persistence rule guidelines

Settings Guidelines
Name Configuration name. Valid characters are A-Z, a-z, 0-9, _, and -. No spaces. You reference this name in the virtual server configuration.

Note: After you initially save the configuration, you cannot edit the name.
Type Select a persistence type.
Source Address
Source Address Persistence is based on source IP address.
Timeout

Timeout for an inactive persistence session table entry. The default is 300 seconds. The valid range is 1-86,400.

Subnet Mask Bits (IPv4) Number of bits in a subnet mask to specify a network segment that should following the persistence rule. For example, if IPv4 maskbits is set to 24, and the backend server A responds to a client with the source IP 192.168.1.100, server A also responds to all clients from subnet 192.168.1.0/24.
Subnet Mask Bits (IPv6) Number of bits in a subnet mask to specify a network segment that should following the persistence rule.
Match across servers

Enable so clients continue to access the same backend server through different virtual servers for the duration of a session.

For example, a client session with a vSphere 6.0 Platform Services Controller (PSC) has connections on the following ports: 443, 389, 636, 2012, 2014, 2020. A FortiADC deployment to load balance a cluster of vSphere PSCs includes Layer 4 virtual server configurations for each of these ports. To ensure a client’s connections for a session go to the same backend real server:

  1. Create a persistence object based on Source Address affinity and select the Match Across Servers option.
  2. Select this persistence object in each of the Layer 4 virtual servers configured to load balance the vSphere PSC pool.
  3. Select the same real server pool object in each of the Layer 4 virtual servers configured to load balance the vSphere PSC pool.

When these options are enabled, FortiADC dispatches the intial connection to a real server destination (for example, RS1) based on the virtual server’s load balancing method, and the persistence object is noted in the connection table. Subsequent connection attempts with the same source IP address to any FortiADC virtual server that has this persistence object and real server pool are dispatched to RS1, as long as the session is active.

Note: In the Layer 4 virtual server configuration, you specify a packet forwarding method. You can use Source Address persistence with Match Across Servers with any combination of Direct Routing, DNAT, and Full NAT packet forwarding methods. However, with NAT46 and NAT64 packet forwarding methods, the source address type is different from the real server address type. To use Match Across Servers with NAT46 or NAT64, all virtual servers for the application must be configured with the same packet forwarding method: all NAT46 or all NAT64.

Source Address Hash
Source Address Hash Persistence is based on a hash of the IP address of the client making an initial request.
Source Address-Port Hash
Source Address-Port Hash Persistence is based on a hash of the IP address and port of an initial client request.
HTTP Header Hash
HTTP Header Hash Persistence is based on a hash of the specified header value found in an initial client request.
Keyword A value found in an HTTP header.
HTTP Request Hash
HTTP Request Hash Persistence is based on a hash of the specified URL parameter in an initial client request.
Keyword A URL parameter.
Cookie Hash
Cookie Hash Persistence is based on a hash of the cookie provided by the backend server.
Persistent Cookie
Persistent Cookie Persistence is based on the cookie provided in the backend server response. It forwards subsequent requests with this cookie to the original backend server.
Keyword Backend server cookie name.
Timeout

Timeout for an inactive persistence session table entry. The default is 300 seconds. The valid range is 1-86,400.

Insert Cookie
Insert Cookie Persistence is based on a cookie inserted by the FortiADC system.

The system inserts a cookie whose name is the value specified by Keyword and whose value is the real server pool member Cookie value and expiration date (if the client does not already have a cookie).

For example, if the value of Keyword is sessid and the real server pool member Cookie value is rs1, FortiADC sends the cookie sessid=rs1|U6iFN to the client, where U6iFN is the expiration date as a base64 encoded string.
Keyword Specifies the cookie name.
Timeout

Timeout for an inactive persistence session table entry. The default is 300 seconds. The valid range is 1-86,400.

Rewrite cookie
Rewrite Cookie Persistence is based on the cookie provided in the backend server response, but the system rewrites the cookie.

The system checks the HTTP response for a Set-Cookie: value that matches the value specified by Keyword. It replaces the keyword value with the real server pool member Cookie value.

For example, the value of Keyword in the persistence configuration is sessid. The real server pool member Cookie value is rs1. After an initial client request, the response from the server contains Set-Cookie: sessid=666, which FortiADC changes to Set-Cookie: sessid=rs1. FortiADC uses this rewritten value to forward subsequent requests to the same backend server as the original request.
Keyword Specifies a Set-Cookie: value to match.
Embedded Cookie
Embedded Cookie

Persistence is based on the cookie provided in the backend server response.

Like Rewrite Cookie, the system checks the HTTP response for a Set-Cookie: value that matches the value specified by Keyword in the persistence configuration. However, it preserves the original value and adds the real server pool member Cookie value and a ~ (tilde) as a prefix.

For example, the value of Keyword is sessid. The real server pool member Cookie value is rs1. After an initial client request, the response from the server contains Set-Cookie: sessid=666, which the system changes to Set-Cookie: sessid=rs1~666. It uses this rewritten value to forward subsequent requests to the same backend server as the original request.

Keyword Specifies a Set-Cookie: value to match.
RADIUS Attribute
Type

Select RADIUS Attribute.

Timeout

Specify the timeout for an inactive persistence session table entry. The default is 300 seconds, and valid values range from 1 to 86,400.

Match Across Virtual Servers

OFF (disabled) by default. Click the button to enable it.

If enabled, clients will continue to access the same backend server through different virtual servers for the duration of a session.

Override Connection Limit

OFF (disabled) by default, which means that when the connection limit is reached, new connections will still be persistently forwarded to the real server.

If enabled, new connections will be forwarded to another node (load-balancing) until all nodes are full.

RADIUS Attribute Relation

RADIUS persistence rule supports multiple RADIUS settings, which can be either of the following relations:

  • AND (Default) — The persistence condition is true if all RADIUS attributes are found.
  • OR—The persistence condition is true if any of the attributes is found.
RADIUS Attribute

After you have saved the RADIUS-tyoe persistence configuration object, you can open the Persistence configuration editor and add up to four (4) RADIUS attributes to it.

Note: If you choose to use the 26-Vendor-Specific attribute, you need to specify the Vendor ID and Vendor Type.

RDP Cookie
RDP Cookie Persistence based on RDP cookie sent by RDP clients in the initial connection request.
SSL Session ID
SSL Session ID Persistence is based on SSL session ID.
Timeout

Timeout for an inactive persistence session table entry. The default is 300 seconds. The valid range is 1-86,400.

SIP Call ID
SIP Call ID Persistence is based on SIP Call ID. For SIP services, you can establish persistence using Source Address, Source Address Hash, or SIP caller ID.
Timeout

Timeout for an inactive persistence session table entry. The default is 300 seconds. The valid range is 1-86,400.

Configuring persistence rules

Persistence rules identify traffic that should not be load balanced, but instead forwarded to the same backend server that has seen requests from that source before. Typically, you configure persistence rules to support server transactions that depend on an established client-server session, like e-commerce transactions or SIP voice calls.

The system maintains persistence session tables to map client traffic to backend servers based on the session attribute specified by the persistence rule.

The persistence table is evaluated before load balancing rules. If the packets received by the ADC match an entry in the persistence session table, the packets are forwarded to the server that established the connection, and load balancing rules are not applicable.

Most persistence rule types have a timeout. When the time that has elapsed since the system last received a request from the client IP address is greater than the timeout, the system does not use the mapping table to forward the request. Instead, it again selects the server using the method specified in the virtual server configuration. Hash-based rule types have a timeout built into the hash algorithm. For other types, you can specify the timeout.

Predefined persistence rules describes the predefined persistence rules. You can get started with these commonly used persistence methods or create custom objects.

Predefined persistence rules

Predefined Description

LB_PERSIS_SIP

Persistence based on source IP address or subnet.

LB_PERSIS_CONSISTENT_SIP

Persistence based on a hash of source IP address.

LB_PERSIS_HASH_SRC_ADDR_PORT

Persistence based on a hash that includes source IP address and port.

LB_PERSIS_HASH_COOKIE

Persistence based on a hash of a session cookie provided by the backend server.

LB_PERSIS_RDP_COOKIE

Persistence based on RDP cookie sent by RDP clients in the initial connection request.

LB_PERSIS_SSL_SESS_ID

Persistence based on the SSL session ID.

LB_PERSIS_SIP_CALL_ID

Persistence based on the SIP call ID.

LB_PERSIS_PASSIVE_COOKIE

Persistence based on a passive cookie generated by the server. FortiADC does not generate or manage the cookie, but only observes it in the HTTP stream, thus the name "passive cookie". Also known as "server cookie".

Before you begin:

  • You must have a good understanding and knowledge of the applications that require persistent sessions and the methods that can be used to identify application sessions.
  • You must have Read-Write permission for Load Balance settings.

After you have configured a persistence rule, you can select it in the virtual server configuration.

To configure a persistence rule:
  1. Go to Server Load Balance > Application Resources.
  2. Click the Persistence tab.
  3. Click Create New to display the configuration editor.
  4. Give the rule a name, select the type, and specify rule settings as described in Persistence rule guidelines.
  5. Save the configuration.

 

You can clone a predefined configuration object to help you get started with a user-defined configuration.

To clone a configuration object, click the clone icon that appears in the tools column on the configuration summary page.

 

Persistence rule guidelines

Settings Guidelines
Name Configuration name. Valid characters are A-Z, a-z, 0-9, _, and -. No spaces. You reference this name in the virtual server configuration.

Note: After you initially save the configuration, you cannot edit the name.
Type Select a persistence type.
Source Address
Source Address Persistence is based on source IP address.
Timeout

Timeout for an inactive persistence session table entry. The default is 300 seconds. The valid range is 1-86,400.

Subnet Mask Bits (IPv4) Number of bits in a subnet mask to specify a network segment that should following the persistence rule. For example, if IPv4 maskbits is set to 24, and the backend server A responds to a client with the source IP 192.168.1.100, server A also responds to all clients from subnet 192.168.1.0/24.
Subnet Mask Bits (IPv6) Number of bits in a subnet mask to specify a network segment that should following the persistence rule.
Match across servers

Enable so clients continue to access the same backend server through different virtual servers for the duration of a session.

For example, a client session with a vSphere 6.0 Platform Services Controller (PSC) has connections on the following ports: 443, 389, 636, 2012, 2014, 2020. A FortiADC deployment to load balance a cluster of vSphere PSCs includes Layer 4 virtual server configurations for each of these ports. To ensure a client’s connections for a session go to the same backend real server:

  1. Create a persistence object based on Source Address affinity and select the Match Across Servers option.
  2. Select this persistence object in each of the Layer 4 virtual servers configured to load balance the vSphere PSC pool.
  3. Select the same real server pool object in each of the Layer 4 virtual servers configured to load balance the vSphere PSC pool.

When these options are enabled, FortiADC dispatches the intial connection to a real server destination (for example, RS1) based on the virtual server’s load balancing method, and the persistence object is noted in the connection table. Subsequent connection attempts with the same source IP address to any FortiADC virtual server that has this persistence object and real server pool are dispatched to RS1, as long as the session is active.

Note: In the Layer 4 virtual server configuration, you specify a packet forwarding method. You can use Source Address persistence with Match Across Servers with any combination of Direct Routing, DNAT, and Full NAT packet forwarding methods. However, with NAT46 and NAT64 packet forwarding methods, the source address type is different from the real server address type. To use Match Across Servers with NAT46 or NAT64, all virtual servers for the application must be configured with the same packet forwarding method: all NAT46 or all NAT64.

Source Address Hash
Source Address Hash Persistence is based on a hash of the IP address of the client making an initial request.
Source Address-Port Hash
Source Address-Port Hash Persistence is based on a hash of the IP address and port of an initial client request.
HTTP Header Hash
HTTP Header Hash Persistence is based on a hash of the specified header value found in an initial client request.
Keyword A value found in an HTTP header.
HTTP Request Hash
HTTP Request Hash Persistence is based on a hash of the specified URL parameter in an initial client request.
Keyword A URL parameter.
Cookie Hash
Cookie Hash Persistence is based on a hash of the cookie provided by the backend server.
Persistent Cookie
Persistent Cookie Persistence is based on the cookie provided in the backend server response. It forwards subsequent requests with this cookie to the original backend server.
Keyword Backend server cookie name.
Timeout

Timeout for an inactive persistence session table entry. The default is 300 seconds. The valid range is 1-86,400.

Insert Cookie
Insert Cookie Persistence is based on a cookie inserted by the FortiADC system.

The system inserts a cookie whose name is the value specified by Keyword and whose value is the real server pool member Cookie value and expiration date (if the client does not already have a cookie).

For example, if the value of Keyword is sessid and the real server pool member Cookie value is rs1, FortiADC sends the cookie sessid=rs1|U6iFN to the client, where U6iFN is the expiration date as a base64 encoded string.
Keyword Specifies the cookie name.
Timeout

Timeout for an inactive persistence session table entry. The default is 300 seconds. The valid range is 1-86,400.

Rewrite cookie
Rewrite Cookie Persistence is based on the cookie provided in the backend server response, but the system rewrites the cookie.

The system checks the HTTP response for a Set-Cookie: value that matches the value specified by Keyword. It replaces the keyword value with the real server pool member Cookie value.

For example, the value of Keyword in the persistence configuration is sessid. The real server pool member Cookie value is rs1. After an initial client request, the response from the server contains Set-Cookie: sessid=666, which FortiADC changes to Set-Cookie: sessid=rs1. FortiADC uses this rewritten value to forward subsequent requests to the same backend server as the original request.
Keyword Specifies a Set-Cookie: value to match.
Embedded Cookie
Embedded Cookie

Persistence is based on the cookie provided in the backend server response.

Like Rewrite Cookie, the system checks the HTTP response for a Set-Cookie: value that matches the value specified by Keyword in the persistence configuration. However, it preserves the original value and adds the real server pool member Cookie value and a ~ (tilde) as a prefix.

For example, the value of Keyword is sessid. The real server pool member Cookie value is rs1. After an initial client request, the response from the server contains Set-Cookie: sessid=666, which the system changes to Set-Cookie: sessid=rs1~666. It uses this rewritten value to forward subsequent requests to the same backend server as the original request.

Keyword Specifies a Set-Cookie: value to match.
RADIUS Attribute
Type

Select RADIUS Attribute.

Timeout

Specify the timeout for an inactive persistence session table entry. The default is 300 seconds, and valid values range from 1 to 86,400.

Match Across Virtual Servers

OFF (disabled) by default. Click the button to enable it.

If enabled, clients will continue to access the same backend server through different virtual servers for the duration of a session.

Override Connection Limit

OFF (disabled) by default, which means that when the connection limit is reached, new connections will still be persistently forwarded to the real server.

If enabled, new connections will be forwarded to another node (load-balancing) until all nodes are full.

RADIUS Attribute Relation

RADIUS persistence rule supports multiple RADIUS settings, which can be either of the following relations:

  • AND (Default) — The persistence condition is true if all RADIUS attributes are found.
  • OR—The persistence condition is true if any of the attributes is found.
RADIUS Attribute

After you have saved the RADIUS-tyoe persistence configuration object, you can open the Persistence configuration editor and add up to four (4) RADIUS attributes to it.

Note: If you choose to use the 26-Vendor-Specific attribute, you need to specify the Vendor ID and Vendor Type.

RDP Cookie
RDP Cookie Persistence based on RDP cookie sent by RDP clients in the initial connection request.
SSL Session ID
SSL Session ID Persistence is based on SSL session ID.
Timeout

Timeout for an inactive persistence session table entry. The default is 300 seconds. The valid range is 1-86,400.

SIP Call ID
SIP Call ID Persistence is based on SIP Call ID. For SIP services, you can establish persistence using Source Address, Source Address Hash, or SIP caller ID.
Timeout

Timeout for an inactive persistence session table entry. The default is 300 seconds. The valid range is 1-86,400.