Reset X-Forwarded- For header to last
2. Load balancing
2.3. Load balancing settings
The load balancing settings control the behaviour of the Load Balancer.
When checked Web Security Manager will issue a cookie when a user first connects to the virtual host being proxied / load balanced.
Web Security Man- ager COOKIE based session persistence
Check box
The cookie binds the session to the real server selected by the load balancer ensuring that the users session with the real server is not broken. This method requires that visitors have support for cookies en- abled in their browser.
Despite the name this feature works equally well with HTTPS and HTTP. When checked Web Security Manager will bind the user session to the real server based on a hash of a selected client request header.
HEADER based ses- sion persistence
Check box
The header to use for calculating load balancing hash when header based session persistence is selected.
Header
Input field
Valid input
An HTTP-header sent by the client. Default value
User-Agent
When checked Web Security Manager will bind the user session to the real server based on the visitors source IP.
SOURCE IP based session persistence
Check box This method ensures that requests from visitors with cookie support disabled will be sent to the same server every time.
To compensate for visitors changing IP address during the session (for instance because their requests are sent through different forward proxies) a mask is applied to the users source address (below). Applying a mask ensures that even if the users IP address changes the same server is selected.
The mask to be applied to the visitors source ip address when calculating destination real server based on source hashing.
IP mask:
Drop down list
The mask and resulting number of IP addresses within each "load bal- ancing address chunk" is displayed in the drop down.
Valid input
Options from the drop down list Default value
255.255.240.000 (4,096 hosts)
When checked Web Security Manager will attempt to redirect a request to another real server in case the real server to which the session is bound fails.
Enable real server failover
Check box
Disabling real server failover only is effective when session persistence is enabled.
If real server failover is disabled the user will receive an error message and the session will have to be restarted (usually by closing and restart- ing the browser).
Maximum failover attempts in case a real server fails.
Max real server fail- over attempts
Input field
This value defines how many times Web Security Manager should try other real servers in case a real server fails.
Valid input
Number in range 1 - (number of real servers -1) Input example
1
Default value
1
Specifies for how long a failed real server should be kept in error state before trying to connect again.
Real server retry in- terval (seconds)
Input field Valid input
Number in range 1 - Input example 20 Default value 60
2.4. Health Checking
Health checking checks the real (backend) servers for errors and availability. If a server is not re- sponding correctly (as configured) it is disabled until it responds correctly again.
Enable / disable health checking
Enable real server health checking
Check box
Default: <disabled>
How often the health check daemon should check the server.
Request interval
Input field Valid input
Number in range 10 - 60 Default value
10
Max time to wait for real server to respond before marking the attempt as failed. Request timeout input field Valid input Number in range 1 - 30 Default value 2
Specifies how many failed health checks should be recorded before the server is disabled.
Error threshold
Valid input
Number in range 1 - 10 Default value
3
What method should be used for health checking.
Request method
drop-down list Valid input
HEAD or GET
Default value
HEAD
The HEAD method only checks the server response code. If the server returns 200 OK within the configured timeout the request is a success. The GET method validates the page the server returns using a check- sum. If the content of the page has changed (compared to the stored checksum) the request is marked as failed.
Note
If the request method is GET and the content of the requested resource is changed on all servers, all servers will be disabled as they will fail the checksum check. be sure to run a checksum re-generation immediately after such an update.
The resource to request when health checking.
Request
Input field Valid input
A string starting with / specifying an application, static page, graphic or other content on the web server.
Input example /testpage.php /index.aspx?showpage=999999 /graphics/1x1.gif Default value <none>
When request method GET is selected, when settings are saved Web Security Manager request the configured resource on all real servers
Force checksum re- generation
Check box to calculate a checksum which will be stored for further health checking. If the checksum is not the same on all servers Web Security Manager will return an error and the new settings will not be saved.
The checksum is only generated when things change, like when a new Request is configured or method is changed to GET.
There can be situations though where it is desirable to have the check- sum re-generated, for instance if the content of the request page has changed.
If this option is checked the checksum will be re-generated. Default: <disabled>