Global Settings #

The Eproxy profile is responsible for managing content switching at the application layer of the OSI model. It supports HTTP, HTTPS, and HTTP/2 protocols, ensuring efficient traffic handling for modern web applications. Additionally, the profile offers hot restart functionality, enabling seamless updates and configuration changes without disrupting active connections.

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 (stop and then start).
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 Eproxy farms profile, the HTTP header X-Forwarded-For is automatically filled with the client IP address.

Currently, only a default service with Virtual Host and Path Pattern matching is supported.

Basic configuration #

The following are the basic parameters for the Eproxy 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 with HTTP2 Application-Layer Protocol Negotiation (ALPN), manage SSL handshakes, handle secure cipher configurations and SSL certificate, to perform SSL offloading. This will relieve the real application servers from these heavy tasks. Also, this mode can be used as HTTP/2 to HTTP/1.1 gateway and viceversa.

HTTPS Parameters #

HTTPS Parameters can be found below.

Disable TLSv1, Disable TLSv1.1, Disable TLSv1.2, Disable TLSv1.3. 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.

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 #

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 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 30 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 20 seconds.

Services Settings #

The services within an LSLB farm using an Eproxy 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, 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.

The default service is preloaded matching all Virtual Hosts and Path 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.

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.
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.

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. HTTP/1.1 or HTTP/2 backend services are supported.

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:

• 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.