Global Settings #

The HTTP profile handles content-switching at the application layer of the OSI model for both HTTP and HTTPS protocols. This profile is designed to intelligently distribute incoming web traffic across multiple backend resources by analyzing the content of incoming requests and making routing decisions based on parameters such as the URL, cookies, headers, and session information. Using this information, it directs traffic to the appropriate server pools.

In the top right section, we have 2 Indicators. Actions buttons and the Status.
Square box: When clicked, the LSLB farm will stop.
Refresh button: When clicked, the Farm will restart.
Play button: If the farm is off or inactive, it will start when clicked.

Each of the colors described below represents the Status of a given Farm:
Green: Means the farm is UP and all backends are running. It could also mean a redirect is configured.
Red: Means the farm is DOWN or it is unfunctional.
Black: Indicates a CRITICAL damage. Usually occurs when a farm is UP but there is no available backend, or they could be in maintenance mode.
Blue: Shows when there is a PROBLEM. The farm could be running but when at least one backend is down.
Orange: Represents MAINTENANCE. Shows when the farm is running but at least one backend is in maintenance mode.

These color codes are consistent throughout the graphical user interface. For a concise explanation, refer to the LSLB Farm Section.

In the HTTP(S) farms profile, the HTTP header X-Forwarded-For is automatically filled with the client IP address.

As a reverse proxy, each HTTP(S) farm (or virtual service) manages multiple services. This means one HTTP virtual IP and port pair can handle more than one load-balanced web service. Therefore, within the HTTP farm, there is a service section that offers virtual host flexibility and allows the creation of backend lists for each service.

Each HTTP(S) service uses regular expressions (for virtual host and URL pattern) in PCRE to identify specific patterns in the HTTP headers of inbound connections. If a pattern matches in both the virtual host and URL pattern fields, the backends for that particular service will process those inbound connections.

Basic configuration #

The following are the basic parameters for the HTTP/S farm profile.

Name. This is a name that easily identifies a farm. To change a name of a given farm, you have to stop it first. Ensure that a new name is not in use already.

Virtual IP and Port. These are the virtual IP addresses and port pairs from which the farm will listen for incoming connections. The new IP address and port combination must be unused and available before being configured.

Listener. This field specifies the layer 7 protocol to perform content switching.

• HTTP. The virtual service will only receive plain HTTP content.
• HTTPS. The virtual service will receive Secure HTTP content, manage SSL handshakes, handle secure cipher configurations, SSL certificates (wildcard or SNI), etc, to perform SSL offloading. This will relieve the real application servers from these heavy tasks.

HTTPS Parameters #

HTTPS Parameters can be found below.

Disable SSLv2, Disable SSLv3, Disable TLSv1, Disable TLSv1.1, Disable TLSv1.2. Each of these toggle buttons enables or disables the associated SSL or TLS version. Disabling any of the protocols is not recommended as its associated ciphers will also be disabled. TLSv1.3 is enabled by default.

Ciphers. This section is where we build lists of ciphers that we use to strengthen an SSL connection. Before a client and server start to exchange information protected by the TLS protocol, they must securely exchange or agree upon an encryption key and a cipher to use when encrypting data.

To configure a cipher for use, select one of the following options.

• All. With this command selected, the listening HTTP(S) farm will manage all the available cipher suites. This is the default setting.
• High security. This command enables the following ciphers:

kEECDH+ECDSA+AES128:kEECDH+ECDSA+AES256:kEECDH+AES128:kEECDH+AES256:kEDH+AES128:kEDH+AES256:DES-CBC3-SHA:+SHA:!aNULL:!eNULL:!LOW:!kECDH:!DSS:!MD5:!EXP:!PSK:!SRP:!CAMELLIA:!SEED

Enabling this option offers security strong enough to pass with an A+ grade in SSL Labs .

• Custom security. This command lets you customize your own ciphers through the Custom Ciphers field.
• Custom ciphers. This command lets you customize specific ciphers to allow or forbid when making an SSL connection. It must be a string in the same format as in OpenSSL ciphers . This command will be displayed if Custom security is set.
• AES SSL HW Offloading. This option enables the AES ciphers to be offloaded via hardware if the processor allows the aes flag. This will allow to optimize the performance of the SSL encryption/decryption task. Test if this option is compatible with your current CPU by running the following command. If the CPU flags are displayed, then it can be used.

root@noid-ee-02:~# grep "flags.* aes" /proc/cpuinfo

Available Certificates: These are the SSL certificates installed on the device. To enable a certificate, select it and click the arrow button or drag and drop it from the Available box to the Enabled box. You can also enable/disable multiple certificates or all of them.

Enabled Certificates: This list shows the certificates currently in use by the farm. You can move them to the top or bottom using the double up/down arrows or disable all of them. Note the order of the certificates; if a wildcard certificate is placed before a host certificate, the wildcard will be used first.

Advanced settings #

HTTP Verbs Accepted: This field specifies the HTTP methods that will be used to validate HTTP client requests. If a client’s request uses an unsupported method, an error message will be displayed. Each verb also encompasses additional lower-level methods.

• Standard HTTP request. Standard HTTP requests (GET, POST, HEAD).
• + extended HTTP request. extended HTTP requests (PUT, DELETE).
• + options HTTP verb. extended HTTP requests (PUT, DELETE).
• + standard WebDAV verbs. standard WebDAV verbs (LOCK, UNLOCK, PROPFIND, PROPPATCH, SEARCH, MKCOL, MOVE, COPY, OPTIONS, TRACE, MKACTIVITY, CHECKOUT, MERGE, REPORT).
• + MS extensions WebDAV verbs. MS extensions WebDAV verbs (SUBSCRIBE, UNSUBSCRIBE, NOTIFY, BPROPFIND, BPROPPATCH, POLL, BMOVE, BCOPY, BDELETE, CONNECT).
• + MS RPC extensions verbs. MS RPC extensions verbs (RPC_IN_DATA, RPC_OUT_DATA).

Ignore 100 Continue: If enabled, the 100 Continue feature will be disabled. According to the HTTP 1.1 protocol, this header signals that the form data should not be sent with the initial request. Instead, it sends the header to the web server backend, which responds with 100 (Continue). This indicates that the server has received the request headers and the client should proceed with sending the request body (for example, in a POST request). This feature is designed to prevent inefficient data transmission by ensuring the server checks if the request can be accepted based on the headers alone. Clients must send Expect: 100-continue as a header and wait for a 100 Continue status code before proceeding, or a 417 Expectation Failed if the request is rejected.

Logs: Enable or disable farm traffic logs to debug and analyze the traffic passing through the load balancer.

Backend Connection Timeout: This value sets the time the farm will wait for a connection to the backend, usually the socket opening wait time, in seconds. The default is 20 seconds.

Frequency to Check Resurrected Backends: This setting determines how often the load balancer checks if a previously blacklisted backend is reachable and removes it from the blacklist if it is up. The farm checks the backend periodically once it is marked down, regardless of new client connections. The default is 10 seconds.

Backend Response Timeout: This value sets the time the farm will wait for a response from the backends in seconds. The default is 45 seconds.

Client Request Timeout: This value sets the time the farm will wait for a client’s request. If no data is received within this timeout period, the connection will be terminated. The default is 30 seconds.

HTTP error messages #

The farm service will display custom messages on your site when specific web code errors are detected from the real servers. Personalized HTML pages will be shown for error codes 414, 500, 501, 503, and WAF 403.

• 414: Request-URI Too Long. This error occurs when the URI exceeds the maximum allowed length. If you receive this error, shorten the length of the URL.
• 500: Internal Server Error. This error indicates that the backend encountered an unexpected command.
• 501: Not Implemented. This error occurs when the request verb is not recognized or managed by the proxy or backend.
• 503: Service Unavailable. This error indicates that the proxy could not find an available backend for the request. This might occur if all backends are down or if the request’s regular expression does not match any configured service.
• WAF 403: Forbidden. This error occurs if the Web Application Firewall (WAF) is enabled and the WAF engine rejects the request.

Headers #

In this section, you can globally add or delete request and response headers, applying these actions to all configured services. If a header is configured in the service section, that specific configuration will be overridden.

The actions to use in this section include:

Create rule. A global header rule will be created.
Delete. A global header rule will be deleted.

This section allows you to add or create Header requests and responses, as illustrated in the image below.

Type.

• Request: remove header. Removes the specified header pattern from client HTTP requests.
• Request: add header. Adds the specified header to client HTTP requests.
• Response: remove header. Removes the specified header pattern from backend HTTP responses.
• Response: add header. Adds the specified header to backend HTTP responses.

Services Settings #

The services within an LSLB farm using an HTTP profile enable content-switching for web virtual services, consolidating multiple web applications under the same virtual IP and PORT. This setup facilitates centralized management of web applications, virtual host configurations, URL management, redirection setups, and persistence and backend configurations per service. Each service in an LSLB farm includes properties for health checks, persistence, header management, and a backend list. Regular expressions can be applied to match conditions that dictate which service handles each request.

The HTTP farm profile evaluates service match conditions in priority mode (modifiable as needed). If no service matches, the farm returns an HTTP error 503. Hence, defining multiple services with specific conditions is supported. Requests match services based on virtual host and/or URL patterns.

It’s essential to first create and add at least one backend server to a service. After applying the new service, HTTP services are evaluated sequentially from top to bottom in the list order. The first service to match in the Host and/or URL fields processes the incoming request based on configured URL or Host patterns.

The conditions that need to be matched are:

Virtual Host. This feature allows you to define a condition based on the domain name using the same virtual IP and port within an HTTP farm. If you want to remove this condition, you can leave the field empty. Regular expressions in PCRE format are supported in this field.

URL pattern. The purpose of this field is to identify a web service based on the URL path that the client is requesting. The URL will be evaluated against a designated pattern, ensuring its syntax is correct. If you wish to disregard this condition, you can leave the field empty. Regular expressions in PCRE format are supported in this field, allowing for advanced pattern matching.

The Virtual Host and URL pattern values are regular expressions. If left empty, any value will match. Both fields must match or it’ll skip to the next service. It is recommended to use at least one, serving as the default if there is no match detected at the bottom.

Load balancing scheduler. This field specifies the algorithm used to distribute the load among backend servers. The default selected algorithm is weight-based.

• Weight: connection linear dispatching by weight. Distributes connections based on assigned weights to each backend. Requests are delivered probabilistically according to the defined weights.
• Least Response: dynamic weight according to the backend response. Adjusts backend weights dynamically based on their response times. Faster responses increase the likelihood of connections being directed to these servers.

Redirect #

If the service has the redirect option enabled, backend servers may not be used as all the requests will be sent to the specified URL.

Redirect Type. There are two types of redirects:

• Default: Takes the URL as an absolute host and path to redirect to.
• Append: Appends the original request path to the specified host and path.

Redirect URL. Specifies where the client should be redirected after receiving a response. If a redirect value is configured, you cannot configure backends for this service.. When both the Virtual Host and URL pattern match, the appliance sends an HTTP Location Header response to redirect the client to the configured URL.

Redirect Code. Specifies the HTTP status code for redirection:

• 301 (Moved Permanently)
• 302 (Moved Temporarily)
• 307 (Temporary Redirect)

Persistence #

This parameter defines how the HTTP service manages client sessions and controls which HTTP connections are maintained to ensure stable client sessions. Once a type of persistence session is selected, its Time To Live (TTL) in seconds will be displayed.

No persistence. This option allows HTTP or HTTPS requests to be delivered to real servers without managing client sessions.
IP: Client address. This option uses the client’s IP address to maintain open client sessions across real servers.
BASIC: Basic authentication. This option utilizes the HTTP basic authentication header to control client sessions. For example, when a web page requires basic authentication from the client, an HTTP header will contain a string like the following:

		HTTP/1.1 401 Authorization Required
		Server: HTTPd/1.0
		Date: Sat, 27 Nov 2011 10:18:15 GMT
		WWW-Authenticate: Basic realm="Secure Area"
		Content-Type: text/HTML
		Content-Length: 31

Then the client answer with the header:

                GET /private/index.html HTTP/1.1
		Host: localhost
		Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

This basic authentication string is used as an ID for the session to identify the client session.
PARM: A URI parameter. Another way to identify a client session is through a URI parameter separated from a semicolon character that is used as a user session identifier. In the example http://www.example.com/private.php;EFD4Y7 the parameter will be used as the session identifier.
URL: A request parameter. When the session ID is sent through a GET parameter with the URL, this parameter indicates that the name associated with the client session ID will be possible. For example, a client request like http://www.example.com/index.php?sid=3a5ebc944f41daa6f849f730f1 should be configured with the parameter Persistence Session Identifier (sid value in this example) and the persistence session time to life (TTL)
COOKIE: . You’ will be able to select an HTTP cookie variable to read from the HTTP Headers and use it to maintain client sessions for a given time. The configured cookie name in the persistence session identifier field is created by a programmer and embedded into a webpage to identify the client session, for example:

                GET /spec.html HTTP/1.1
                Host: www.example.org
                Cookie: sessionidexample=75HRSd4356SDBfrte

Additionally, Persistence session Time To Life (TTL) should be configured. This value manages the time that the load balancer saves when the client and the backend go without any activity.
HEADER: a request header. An HTTP header custom field could be used to identify the client session. The persistence session Time To Life and persistence session identifier is required to be configured. For example:

               GET /index.html HTTP/1.1
               Host: www.example.org
               X-sess: 75HRSd4356SDBfrte

Cookie Insert #

If configured, the load balancer will generate a cookie in each response using the appropriate backend key. This ensures that even if the session table is cleared or sessions are disabled, the correct backend will still be selected. This feature eliminates the need to modify the real server code to create a session cookie.

The Cookie Name specifies the name of the cookie created and included in the client request or backend response. The Cookie Path defines the URI or relative path where the new cookie will be established. To apply the cookie across the entire domain, set this field accordingly. The Cookie Domain indicates the domain where the cookie will be set. Lastly, the Cookie TTL denotes the number of seconds the cookie remains active between the client and backend. This value must exceed 0, and it relates to the duration without any activity. Once the specified time passes without activity, the persistence session associated with the cookie will expire.

Farmguardian #

HTTP farms provide a basic and native backend health check but the Farmguardian configuration is recommended for smarter heuristics backend health checks to ensure that the application is healthy.

Some built-in or customized advanced health checks can be assigned to this service from the already created farmguardian checks.

For further Farmguardian information go to the Monitoring > Farmguardian section.

Notice that after selecting the farmguardian, it will be automatically applied to the farm.

HTTPS Backends. This checkbox indicates to the farm that the backend servers defined in the current service are using the HTTPS protocol so the data will be encrypted before being sent.

Backends #

Regarding the Backends, the HTTP farm profile allows the configuration of the following properties: All the backends must be IPv4 or IPv6, and with the same IP version as the Farm VIP.

Add backend #

Through the Actions menu button, the following actions are available for one or more selected backends:
Add Backend. This command opens the backend creation form.
The actions mentioned above: Enable maintenance (Drain and Cut mode), Disable maintenance and Delete.

Backend List #

Actions. Use the following actions to manage the backends:

• Enable Maintenance. Use this action if the backend was previously disabled. Placing a real server in maintenance mode means that no new connections will be redirected to it. There are two methods for enabling the maintenance mode:
  • Drain Mode. Keeps established connections and persistence if enabled, but will not admit new connections.
  • Cut Mode. Drops all active connections against the backend
• Disable Maintenance. Use this action when the backend is in maintenance mode. Enable new connections to the real server again after disabling maintenance mode.
• Delete. Remove configurations of a selected virtual service. The alias won’t be deleted if there is any.

Alias. Backend alias, if any alias was selected.
IP. The IP address of a given backend.
Port. The port number of the current real server.
Timeout. The time a backend takes to respond. This value overrides the parameter of the global Backend connection timeout but it is limited to this selected farm.
Weight. The weight value for the current real server. More weight indicates more connections delivered to the current backend. By default, a weight value of 1 will be set. The values range available is from 1 to 9.
Status. The possible values are:

• Up. The farm is running and the backend is ready to receive connections.
• Down. The farm is running and the service has detected that the backend is not working
• Maintenance. Backend is marked as not ready for receiving connections by the administrator, this option is useful for backend’s maintenance tasks
• Undefined. The backend status has been not checked.

Priority. The priority value for the current real server. Lower values have more priority. The default service priority value is 1. When a backend fails, the service priority is increased by 1. When the backend is alive again, the service priority value is decreased by 1. Active backends contain priority values less than or equal to the service priority.

IPDS Rules for HTTP farms #

This section allows you to enable IPDS rules. The list displays different types of protection with a select box to activate them. For more information, please refer to the specific documentation for IPDS > Blacklists rules, IPDS > DoS rules, IPDS > RBL rules or IPDS > WAF rules.

For each of the four types of IPDS rules (Blacklist, DoS, WAF, and RBL), there are two lists: Available and Enabled. A chain icon is also present. In the Available list, you will find rules of the same type that can be applied to a given farm. In the Enabled list, you will see the rules currently applied to the selected farm, indicated by their status symbol: red for stopped and green for running.

Each rule can be edited by clicking the edit icon, which allows you to change rule parameters or start/stop the rule. Note that new rules cannot be created within this farm view and must be managed through the IPDS section.

To add a rule, click on the desired rule and then click the right single arrow. You can also select multiple rules by holding the shift key and selecting the desired rules before clicking the right single arrow. To add all available blacklists, click the right double arrow.

To delete one or more rules, select them and click the left arrow or click the double arrow to remove all.