Server load balancing (SLB) features are designed to give you flexible options for maximizing performance of your backend servers. The following topics give an overview of SLB features:

Table 1 summarizes server load balancing features.

For detailed information, see “Server Load Balancing”.

FortiADC SLB supports offloading authentication and authorization from backend servers. The auth policy framework supports authentication against local, LDAP, and RADIUS authentication servers, and it enables you to assign users to groups that are authorized to access protected sites.

For configuration details, see “Configuring auth policies”.

FortiADC SLB supports caching. Caching reduces server overload, bandwidth saturation, high latency, and network performance issues.

When caching is enabled for a virtual server profile, the FortiADC appliance dynamically stores application content such as images, videos, HTML files and other file types to alleviate server resources and accelerate overall application performance.

For configuration details, see “Configuring caching rules”.

FortiADC SLB supports compression offloading. Compression offloading means the ADC handles compression processing instead of the backend servers, allowing them to dedicate resources to their own application processes.

When compression is enabled for a virtual server profile, the FortiADC system intelligently compresses HTTP and HTTPS traffic. Reducing server reply content size accelerates performance and improves response times. FortiADC supports both industry standard GZIP and DEFLATE algorithms.

For configuration details, see “Configuring compression rules”.

FortiADC SLB supports content rewriting rules that enable you to rewrite HTTP requests and responses so that you can cloak the details of your internal network. You can also create rules to redirect requests.

For configuration details and examples, see “Using content rewriting rules”.

FortiADC SLB supports content routing rules that direct traffic to backend servers based on source IP address or HTTP request headers.

For configuration details, see “Configuring content routes”.

FortiADC SLB supports Lua scripts to perform actions that are not currently supported by the built-in feature set. Scripts enable you to use predefined script commands and variables to manipulate the HTTP request/response or select a content route.

For configuration details, see “Using scripts”.

FortiADC SLB supports SSL offloading. SSL offloading means the ADC handles SSL decryption and encryption processing instead of the backend servers, allowing the backend servers to dedicate resources to their own application processes.

SSL offloading results in improved SSL/TLS performance. On VM models, acceleration is due to offloading the cryptographic processes from the backend server. On hardware models with ASIC chips, cryptography is also hardware-accelerated: the system can encrypt and decrypt packets at better speeds than a backend server with a general-purpose CPU.

Figure 2 illustrates how FortiADC acts as the SSL/TLS terminator in HTTPS sessions. Instead of a single encrypted tunnel along the entire path from the client to a backend server, the client HTTPS request is decrypted when it reaches the FortiADC system. FortiADC then forwards unencrypted HTTP traffic to your servers. When the server replies, the server connects to the FortiADC via clear text HTTP. FortiADC then encrypts the response and forwards it via HTTPS to the client.

 

First, you import the X.509 v3 server certificates and private keys that ordinarily belong to the backend servers, as well as any certificate authority (CA) or intermediate CA certificates that are used to complete the chain of trust between your clients and your servers. FortiADC acts as an SSL proxy for the server, using the certificates to:

When session data has been decrypted, you can use the FortiADC content rewriting and content routing rules.

When you offload the SSL processes from backend servers to an ADC, the ADC forwards data unencrypted to the servers. You must deploy the FortiADC appliance in a trusted network with direct path to the backend servers. For example, the FortiADC and the backend servers are connected through a switch and all are located physically in the same locked rack. In cases where traffic is forwarded along untrusted paths towards backend servers, you have the option to re-encrypt the data before forwarding it to the backend servers.

An SSL cipher is an algorithm that performs encryption and decryption. It transforms plain text into a coded set of data (cipher text) that is not reversible without a key. During the SSL handshake phase of the connection, the client sends a list of the ciphers it supports. FortiADC examines the client cipher list in the order it is specified, chooses the first cipher that matches a cipher specified in the virtual server configuration, and responds to the client. If none of the ciphers offered by the client are in the cipher suite list for the virtual server, the SSL handshake fails.

To see the list of ciphers supported by the browser you are using, go to a link maintained by the Leibniz University of Hannover Distributed Computing & Security (DCSec) Research Group:

FortiADC SLB profiles support a specific list of RSA ciphers and PFS ciphers.

Table 2 lists supported RSA ciphers. With RSA ciphers, the server's public key is used to encrypt a secret created by the client web browser.

With RSA ciphers, the server's public RSA key is part of the server certificate and is typically very long lived. It is not uncommon for the same public key to be used for months or years. This creates a potential problem: if an SSL server's private key were to leak or be stolen, all connections made in the past using that key would be vulnerable. If someone has recorded your SSL connections, they can use the private key to decrypt them.

Table 3 lists supported Perfect Forward Secrecy (PFS) ciphers.With PFS, a fresh public key is created for every single connection.That means that an adversary would need to break the key for each connection individually to read the communication.

For information on importing X.509 v3 server certificates, see “Using certificates”.

For information on specifying certificates, SSL/TLS versions, and the cipher list in HTTPS and TCPS profiles, see “Configuring profiles”.