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 infrastructure deployed in Selectel, 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 the SSL session ID or based on the HTTP cookie entered.

Health Check is a mechanism for checking the health of servers to prevent load balancing traffic from being sent to idle servers. ICMP ping or other more sophisticated testing of TCP connections is used for verification. Health Check removes idle real servers from the load balancing cluster. Removing 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 accepts sessions. The FortiGate unit sends sessions to the IP address of the real server using the destination port number in the actual 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 be applied only if one of the SSL protocol types (HTTPS, IMAPS, POP3S, SMTPS, SSL) is set for load balancing. FortiGate provides the ability to select which segments of the SSL connection will receive SSL offloading 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 an open (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, i.e., 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 effective 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 ensures that multiple unrelated HTTP or HTTPS requests can be correctly processed in different order on the same connection. Moreover, responses are received as they are ready, hence heavy queries will not block the 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.

Persistence — A parameter that stores and tracks session data to ensure that the 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 you configure Persistence, FortiGate balances the load of the new session on the live server according to the load balancing method. If a 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 techniques⁠

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 the hardware FortiGate-100E, whose initial basic configuration can be done according to firewall configuration instructions. Cloud servers in the Selectel Cloud Platform are used as servers.

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 located on the internal network. HTTP sessions are received on interface wan1 with destination IP address 172.20.120.121 on TCP port 3080 and redirected from the internal interface to the web servers. When forwarding, the session destination address 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 verify functionality, create a Health Check at the HTTP level, for which you can customize the /index.html URL and ctel content in detail.

To configure Health Check, which 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. Enter 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 the 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. From 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 HTTP Cookie.
  7. Select the Health check performance monitor you created earlier by pressing +.
  8. Enable HTTP multiplexing 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 are required to store the client's original IP address, e.g. in log messages.
Bind real servers to virtual⁠
  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 the OK button.

HTTPS⁠

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

Add SSL Certificate⁠
  1. Go to System → Certificates.
  2. Make sure that System → Feature Visibility has Certificates enabled.
  3. Select Import → Local Certificate.
  4. In the window that opens, set Type to 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 SSL Session ID in addition to HTTP Cookie.

To accelerate 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 the real servers between which the load will be balanced. Specify the correct ports on which web servers are deployed for HTTPS traffic, the default is port 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 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 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, policies are created in the same way. The only difference is the selection of the virtual server in the Destination field.
  9. Press the OK button 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.

The following demonstrates 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 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 test 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

Traffic can also be monitored on the server itself, for example with the tcpdump command. The following shows traffic with NAT disabled when configuring a policy for the balancer on the FortiGate so that 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