Skip to main content
Load balancing with FortiGate
Last update:

Load balancing with FortiGate

Load balancing with FortiGate includes all the features you need to distribute traffic across multiple servers in your Selectel-deployed infrastructure, including both dedicated hardware servers and virtual servers in the Selectel Cloud Platform.

FortiGate provides comprehensive protection for your infrastructure and balances server loads by distributing traffic flows according to predefined rules, allowing you to combine load balancer, Next Generation Firewall (NGFW), and threat protection in a single appliance.

Load balancing based on FortiGate solutions provides:

  • fast and reliable processing of requests;
  • significant simplification of the network architecture;
  • reduction of operating costs.

The load balancer supports HTTP, HTTPS, IMAPS, POP3S, SMTPS, SSL or lower-level TCP/UDP or IP protocols. Session persistence is supported based on an SSL session ID or based on an entered HTTP cookie.

Health Check is a mechanism for checking the health of servers to prevent load balancing traffic from being sent to idle servers. The check uses ICMP ping or other more sophisticated testing of TCP connections. Health Check removes idle real servers from the load balancing cluster.The removal of real servers from clusters is based on configuration:

  • Interval — at what frequency the server is checked;
  • Timeout — The maximum allowable response time before the server is considered unavailable;
  • Retry — the number of failures before the server is considered unavailable, after which it is deleted.

Types of Health Check by protocols: TCP, HTTP, PING.

Virtual Server — A virtual server whose external IP address receives traffic that is forwarded to the load balancer.

Real Server — the actual, real server to which requests are received after balancing. Several real servers can be assigned to each virtual server. The Real Server configuration includes the IP address and port number on which the Real Server receives sessions. The FortiGate unit sends sessions to the IP address of the real server using the destination port number in the real server configuration. The server configuration includes its IP address and the port number on which it accepts sessions.

SSL Offloading is a mechanism for accelerating SSL client-to-server connections where encryption operations are performed on the FortiGate unit instead of the servers themselves using a separate, dedicated processor. This mechanism can only be applied if the load balancing is set to one of the SSL protocol types (HTTPS, IMAPS, POP3S, SMTPS, SSL). FortiGate provides the ability to select which segments of the SSL connection will receive SSL offload by defining the mode:

  • Client ⟷ FortiGate — A mode that hardware-accelerated SSL/TLS processing only for the portion of the connection between the client and the FortiGate unit. This mode is called half mode SSL offloading. The segment between the FortiGate unit and the server will use a clear text connection for better performance;
  • Full — A mode that applies hardware-accelerated SSL processing to both parts of the connection: the segment between the client and the FortiGate unit and the segment between the FortiGate unit and the server, that is, Client ⟷ FortiGate ⟷ Server. The segment between the FortiGate unit and the server will use an encrypted connection, but the "handshakes" will be reduced. This is not as efficient as offloading SSL in half mode, but still improves performance.

HTTP multiplexing is a feature that allows a web client to use a single TCP connection for all requests to the server. This feature reduces the load on the web server by establishing a single connection over which requests and responses are sent in parallel. Each fragment is associated using special built-in meta-data, which provides the ability to correctly process multiple unrelated HTTP or HTTPS requests in different order on the same connection. Moreover, responses are received as they are ready, hence heavy requests will not block processing and delivery of simpler objects.

For example, if users' web browsers are only compatible with HTTP 1.0, which does not implement this feature, enabling HTTP multiplexing can improve performance between the web server and the FortiGate unit.

Persistence is a parameter that stores and tracks session data to ensure that a user connects to the same server each time they make a request that is part of the same session or subsequent sessions. HTTP cookie persistence uses embedded cookies to ensure persistence.

When Persistence is configured, the FortiGate unit load balances the load of the new session on the live server according to the load balancing method. If the session has an HTTP cookie or SSL session ID, the FortiGate unit sends all subsequent sessions with the same HTTP cookie or SSL session ID to the same live server.

Load balancing methods⁠

Traffic can be distributed among servers based on methods:

  • static — even distribution of load between servers according to a predefined algorithm, not taking into account the occupancy of servers;
  • round-robin — allocation based on the round-robin algorithm, which performs a round-robin search of peer servers, regardless of response time or number of connections;
  • weighted — distribution based on assigned weights to servers to account for features and differences, where servers with a higher weight value receive a higher percentage of connections;
  • least-session — distribution, in which requests are directed to the server with the smallest number of current connections, it is recommended to use in case of similar server capabilities;
  • least-rtt — Round-Trip-Time based distribution, where requests are routed to the server with the lowest such rate, which is determined by the Ping health check monitor and defaults to 0 if Ping health check is not set;
  • first-alive — distributing the load to the first active server, providing protection against failure: sessions are not distributed among servers, but are processed by one "first" while it is "alive" and then switched to another running server;
  • http-host — an allocation based on the HTTP header of the host to direct the connection to a specific server.

Before setting up the balancer⁠

Before configuring load balancing in the GUI, enable the display of the special settings section.

  1. Go to System → Feature Visibility.
  2. Enable Load Balance in the Additional Features list.

This example will cover Load Balancing settings for HTTP and HTTPS on a hardware FortiGate-100E, whose initial basic configuration can be done following the firewall configuration instructions. The servers used are cloud servers in the Selectel Cloud Platform.

FortiGate and the project in the Cloud platform are connected by a private network that uses a global router network to connect between regions and services, allowing dedicated servers and VMware-based servers in the Cloud to be installed behind the firewall as well.

Customize the balancer⁠

In this configuration, the balancer distributes HTTP traffic from the Internet to three web servers on the internal network. HTTP sessions are received on interface wan1 with a destination IP address of 172.20.120.121 on TCP port 3080 and forwarded from the internal interface to the Web servers. During the forwarding, the destination address of the sessions is converted to the IP address of one of the web servers.

HTTPS traffic is balanced in a similar manner.

Create Health Check⁠

HTTP⁠

To test functionality, create a Health Check at the HTTP level, for which you can customize the URL /index.html and ctel content in detail.

To configure a Health Check that sends get requests to http://<real_server_IP_address>/index.html and searches the returned web page for the phrase "Selectel", follow these steps:

  1. Go to Policy & Objects → Health Check.
  2. Click the Create New button.
  3. Specify a name in the Name field.
  4. Specify the HTTP type in the Type field.
  5. Enter the port in the Port field (the default for HTTP traffic is 80).
  6. Enter the desired phrase in the Matched content field.
  7. Specify other parameters if necessary.

HTTPS⁠

To monitor the health of servers at the HTTPS level, a similar Health Check is created, only without detailed content and URL checking.

Create Virtual server⁠

HTTP⁠

Virtual Server for HTTP⁠

A Virtual server is created, which will receive HTTP requests.

  1. Go to Policy & Objects → Virtual Servers.
  2. Click the Create New button.
  3. Specify the name in the Name field, the HTTP type in the Type field, and the interface in the Interface field.
  4. In Virtual server IP and Virtual server port, the external IP address and port to which requests will be received.
  5. In the Load balancing method drop-down menu, select the load balancing method that is appropriate for your case.
  6. Enable the Persistence option to store session data by selecting the HTTP Cookie value.
  7. Select the Health check performance monitor you created earlier by pressing +.
  8. Enable the HTTP multiplexing option if you want to use a single TCP connection between the web client and the server, including for incoming unrelated requests and responses.
  9. Enable the Preserve client IP option to preserve the client IP address in the X-Forwarded-For HTTP header . This can be useful when enabling HTTP multiplexing if real servers require the original client IP address to be saved, for example, in log messages.
Bind real servers to virtual server⁠
  1. Under Policy & Objects → Virtual Servers, where Virtual Server configuration continues, create Real Servers.
  2. In the Real Servers table, click Create New.
  3. In the window that opens, add the IP address and port of the server you want to connect to. In this case, the HTTP server is deployed on port 80.
  4. Press the OK button.
  5. Add all servers involved in load balancing by repeating steps 1-4.
  6. Save the Virtual Server settings by clicking OK.

HTTPS⁠

The FortiGate load balancer requires an SSL certificate to be downloaded.

Add SSL Certificate⁠
  1. Go to System → Certificates.
  2. Make sure that Certificates is enabled in System → Feature Visibility.
  3. Select Import → Local Certificate.
  4. In the window that opens, set Type — Certificate, download the Certificate file and Key file for your certificate.
  5. Enter the password in the Password field.

After these steps, the server certificate will appear in the Certificates list.

Virtual Server for HTTPS⁠

For HTTPS, a virtual server is created in the same way as for HTTP by specifying the Virtual Server type in the Type field on HTTPS.

As Persistence, there is an option to set an SSL Session ID in addition to HTTP Cookie.

To speed up SSL connection in the SSL Offloading subsection, select the required mode in the Mode field, thus determining which network segment will be offloaded: Client-FortiGate or Full.

Also, select the SSL certificate from the drop-down menu in the Certificate field that you imported earlier.

Bind a real server to a virtual server⁠

In the Real Servers subsection, similarly add real servers between which the load will be balanced. Specify the correct ports on which the web servers are deployed for HTTPS traffic, the default port is 443.

Create a policy⁠

To create a security policy that includes the load balancing virtual server as the destination address:

  1. Go to Policy & Objects → Pv4 Policy.
  2. Click the Create New button.
  3. Specify the name of the policy in the Name field.
  4. Specify the Incoming interface — Incoming interface, Outgoing interface — Outgoing interface, behind which the servers are connected.
  5. In the Source field, select the all object by pressing +.
  6. In the Destination field, select the load balancing virtual server that was created earlier. It is important that the Inspection mode is set to Proxy-based in the policy settings. If the mode is set to Flow-based, the virtual server will be unavailable.
  7. Turn off NAT mode so that the servers can "see" the IP addresses of connected clients.
  8. For the HTTP and HTTPS balancer, the policies are created in a similar way. The only difference is the selection of a virtual server in the Destination field.
  9. Click OK to save the policy settings.

Result⁠

In this example, HTTP traffic load balancing was configured between three servers.

Requests arriving at the virtual server address 172.20.120.121:3080 are redirected to the real servers one by one according to the selected method.

Below is a demonstration of how switching between servers occurs when accessing the same address. For clarity, the content on each server is different.

To enable graphical display of balancer server statuses, go to Monitor → Load Balance Monitor (for FortiOS version 6.2).

You can use the following diagnostic console commands to view status information about load-balanced virtual and real servers:

# diagnose firewall vip realserver ?

For example, the following commands list and display status information about all real servers:

# diagnose firewall vip virtual-server real-server
...
# diagnose firewall vip realserver list

Many diagnostic commands include obtaining information about one or more virtual servers. To control which servers are requested, you can define a filter:

# diagnose firewall vip virtual-server filter ?

The most obvious check is the packet sniffer. The following command in FortiGate can be used to track traffic distribution with port and interface filters set for easier viewing:

# diagnose sniffer pa lan ' port 80 ' ?
...
# diagnose sniffer  pa lan  ' port 80' 5

You can also track traffic on the server itself, for example, by using the tcpdump command. The following shows traffic with NAT disabled when configuring a policy for the balancer on the FortiGate, so you can track the outbound IP address of the client.

root@server1:~# tcpdump -n -i eth1 port 80 and host 192.168.101.2

When NAT is enabled, the FortiGate address is displayed as the outgoing IP address:

root@server1:~# tcpdump -n -i eth1 port 80 and host 192.168.101.2