What do the colored boxes at the top my HA LoadMaster's WUI represent?

The real time status of a HA pair can be obtained by examining the two colored indicators on the header of your WUI display. The first square is the HA1 appliance and the second square is the indicator for the HA2 appliance. When correctly configured the two indicators should be colored green. This should be true for all WUI's (HA Shared IP, HA1, and HA2).

If one of the indicators displays a yellow 'X' with a red background, your LoadMaster is having difficulties contacting its partner. Generally this is due to an error within a configuration on an interface that is used for HA health checks. In a small portion of cases where the LoadMaster's cannot communicate to one another, you may need to contact technical support for further diagnostic assistance.

If one of these indicators is blue, there may be problems with that device. Please contact technical support for assistance.

How do I decide which interfaces to use for HA Checks?

Ideally, HA Checks should be set for every interface that will be in use for production traffic. This includes, but is not limited to the interfaces that are used to pass traffic for virtual services, server pools and default gateway traffic.
HA Checks can also be included on management interfaces, but be aware that LoadMaster will become standby in the event that this network goes down.

For optimal HA operation, at least two interfaces should be configured to use HA Checks. If you only use one interface for all traffic, a crossover cable may be connected between both units on eth1. The interface will automatically configure and no IP addressing should be applied to this link.
The only time you must not have HA Checks enabled is for IP addressed interfaces directly connected to the partner device. This will cause the pair to both fail should the link go down for any reason. This inhibits normal HA function.

I am on my HA pair’s WUI but I do not see any where to add a virtual service, certificate or check my usage statistics.

In addition to the shared management IP, each LoadMaster can be managed directly. This individual web interface allows certain local management tasks, but does not allow the configuration of services. For full configuration options, be sure you are connecting the shared address of the HA pair.

Is there a way to change the interface that is used to send HA updates and persistency updates?

You can select the interface to send and receive inter-HA traffic from within the WUI:

  1. Select the System Configuration > System Administration> HA Parameters option. T
  2. The HA Update Interface setting is used for sending HA configuration updates using TCP/6973 between units.
  3. If you have enabled L7 Persistency Updates or L4 TCP Connection Updates, you will have the additional HA Multicast Interface option as well.

Do you recommend the active use of the feature "Switch to Preferred Server" within HA Parameters?

During normal production the setting for this feature should be "No Preferred Host". We only recommend specifying a host during the testing of HA failover. Setting this to prefer a specific host in production may lead to unexpected failbacks leading to further outages.

My company hosts a website that uses HTTPS. I would like to lessen the burden on the servers by having the LoadMaster decrypt the traffic before it is sent to my server pool, is this possible?

When dealing with encrypted traffic, the LoadMaster has three ways handling such requests.

With this configuration, you will need to import your domain's public certificate and key onto the LoadMaster. This will allow us to decrypt the incoming SSL traffic at the LoadMaster and then pass the traffic to the server unencrypted. In order to support this, the servers must expect and allow secured content to be transmitted over HTTP.

This configuration will require your domain's public certificate and key as well. In this setup, the LoadMaster will decrypt the incoming traffic but will also encrypt the traffic before it is sent off to the server. This allows LoadMaster to perform Layer 7 features without needing to make changes to the server.

  1. SSL pass through.
    • In this situation the LoadMaster would simply allow the SSL traffic to pass unmodified. The LoadMaster would deliver HTTPS traffic the server.
    • SSL pass through will be used if SSL acceleration is not enabled.
  2. SSL offloading.
    • SSL offloading will be used if SSL acceleration is enabled but re-encryption is not.
  3. SSL re-encryption.
    • SSL re-encryption will be used if both SSL acceleration and re-encryption are enabled.

What kind of limitations will I face if I choose to use SSL pass through?

If you do not choose either SSL-offloading or re-encrypting for the incoming SSL traffic, you may notice some configuration limitations. This is due to the fact that the information provide to the LoadMaster is limited to the data that is unencrypted within each packet. This severely limits L7 functionality as only the client's IP address will be viewable.

What is L7 Transparency and why doesn't my virtual service work when it is enabled?

If you choose to enable L7 Transparency within a virtual service, the packets travelling from the LoadMaster to the server will have their IP source listed as that of the client IP. This will enable your servers to log the IP address of the individual requesting clients.

Without transparency, the server logs would only see the LoadMaster making all of the requests. The reason traffic seems to stop flowing with L7 transparency, is due to the fact that the servers then try to respond directly to the client. As the client did not pose its request to the server, it will drop any incoming packets.

The remedy to this problem is to change your server's default gateway to point to LoadMaster's interface which is on the same subnet as the server pool. If you are using a high availability pair, you should choose the shared IP address on the same subnet as the server pool.

My virtual service will be receiving a lot of traffic, in excess of 64,000 open connections. Is there anything I can do to avoid port exhaustion?

LoadMaster may experience port exhaustion in cases of high load where the service is non-transparent. In these cases, you enable option to allow for additional IP addresses to be allotted to any specific virtual service that expects heavy traffic.

In the WUI:

  1. Select the System Configuration > Miscellaneous Options > L7 Configuration option.
  2. Enable the Allow connection scaling over 64K Connections checkbox.
  3. Select the Virtual Services option
  4. Click on the View/Modify Services option
  5. Click the Modify button for the relevant Virtual Service
  6. In the Advanced Options section input the additional addresses you wish to allot for the virtual service in the Alternate Source Addresses field. In order to have an impact, you must specify at least two alternate source addresses.

Clients will continue to request the virtual service address, but connections to real servers will use these addresses as source addresses. Each additional address will add approximately 64,000 new available source ports for relaying client requests.

Where can I specify real server check parameters for my virtual services?

In addition to setting the type of healthcheck to perform on a per virtual service basis, administrators have the ability to specify health check parameters from be selecting the Rules & Checking > Check Parameters option.
From here you can modify your real server check interval, connection timeout and retry count. These govern how aggressively LoadMaster checks the server health. If you are experiencing server “flapping” where real servers are marked as down but immediately return to service, it is recommended that you increase these values to accommodate your servers.

How do I add real servers that are on a subnet that will not be directly connected to the LoadMaster?

In order for non-local real servers to work, transparency must be disabled for that virtual service. All balanced traffic must return through the Load Master, non-transparency forces this to occur. Please note that the performance of the traffic will depend on the connection to the real servers as the traffic will be traveling back out of the local network. Utilizing non-local real servers may induce lag due to the additional round trip time to the servers.

In the WUI:

  1. Select the System Configuration > Miscellaneous Options > L7 Configuration option.
  2. Enable Non-Local Real Servers
  3. Then to add a non-local real servers, go to your virtual service
  4. Confirm that L7 transparency is disabled
  5. Add a new real server.
  6. Enable the Allow Remote Addresses checkbox
  7. Once that is checked, you can add a real service with any IP address.

I cannot remember the password to my 'bal' user, is there a way to reset the password?

To reset the ‘bal’ password, you will need connect directly to your LoadMaster. Performing the follow process via web interface or SSH session will not work.

To reset the password, log on using the user ‘pwreset’ and the password ‘1pwreset’. The console password for the ‘bal’ account will now be temporarily reset to ‘1fourall’. Next you must reset your password using the console. Log in with the newly reset password, and navigate to:

3) Local Administration -> 1) Set Password.

Once this is done you will be able to log in via the web interface and SSH interfaces.

Keep in mind, password changes are local and are not replicated between HA pairs. If you have a HA pair, you will need to perform these steps on both units. Please note that each unit’s ‘bal’ account password can be different although this isn't recommended.

I cannot remember the password to my administratively created user, is there a way to reset the password?

In order to reset a named user, you must be logged in as ‘bal’ or a named user with ‘All Permissions’.

In the WUI:

  1. Select the System Configuration > System Administration > User Management option.
  2. In the Other Users section, click on the Password button of the relevant account.

This will allow you to reset that user's password.

I would like to increase the throughput for traffic going to and from my virtual service. Does the LoadMaster support interface bonding? How would I set this up?

The LoadMaster has the ability to bond its interfaces together to provide for additional throughput as well as redundancy. LoadMaster supports two styles of bonding: 802.3ad and Active-Backup.

To configure an interface for use with bonding:

  1. Navigate to the lowest indexed interface you wish to use on the LoadMaster's web interface.
  2. Click on the Interface bonding button and you will be prompted if you would like to create a bond on this interface This will turn your eth* to bnd*
  3. Configure the bonded interface with addressing
  4. To add interfaces or to modify the bond type click Bonded Devices.
  5. You can select the style of bonding you like from the Bonded Devices page
    • 802.3ad – True bonding which aggregates the bandwidth of multiple interfaces. Both interfaces must connect to the same switch and the switch ports must be configured to support this.
    • Active-Backup – This style of bonding allows for link redundancy but does not aggregate the bonded interfaces. Each link can be connected to a different switch for full redundancy. No switch configuration is required for this.

I would like to use a different interface/IP address for my WUI access, is this possible?

If you wish to change the interface associated with WUI access, navigate your WUI to System Configuration > Misc. Options > Remote Access. The option "Allow Web Administrative Access" has a drop down menu that will allow you to determine which interface to switch WUI access to.

  • Please note that this change takes effect immediately. It is strongly recommended to have access to a host local to the desired subnet. This can be a tricky change to implement. It is recommened that you consult with a Kemp engineer before making any changes to ensure a smooth transition.

What does Transparency mean?

Transparency pertains to how LoadMaster forwards traffic to real servers. In transparent mode, LoadMaster will pass along the original client's IP as the source IP. In non-transparent mode, LoadMaster will NAT the requests to the real server with LoadMaster's virtual service address. In order for your server to see the original sender's IP, you will need to operate transparently.

Transparency can be turned on for Layer 7 services and is always on for Layer 4 services. However, there are some obstacles to services functioning correctly in transparent mode. In order for transparent operation to work correctly, traffic muss return through LoadMaster when returning from the servers. Typically this is done by setting the servers’ default gateway to LoadMaster.

However, challenges arise when the client and server are on the same subnet. In this case transparency cannot not work since the server will respond to the client directly. If you are in a situation where the clients and server are on the same subnet and you must have transparency, I recommend migrating to a two-armed configuration. This can be done by creating an additional subnet connected to LoadMaster and moving your servers there. With LoadMaster as a gateway for the servers, you will be able to operate transparently.

The biggest thing to remember when attempting to operate transparently is that the servers' gateway must be set to LoadMaster. If that is set properly, you can enable transparency by checking the 'L7 Transparency' checkbox under 'Basic Settings.

How can I redirect traffic from HTTP to HTTPS?

To redirect from HTTP to HTTPS, create a virtual service on the IP you use for HTTPS on port 80. This service will act as a redirector and does not need real servers. Once created, scroll down to Advanced Properties. Under Not Available Redirection Handling, select '302 Found' as the Error Code and specify the URL you wish to redirect to as the Redirect URL. You may use the wildcards %h and %s to represent the requested hostname and URI respectively.

Some examples:

  • Redirect URL: https://%h%shttp://example.com/path/to/file.ext https://example.com/path/to/file.ext
  • Redirect URL: https://%hhttp://example.com/path/to/file.ext https://example.com
  • Redirect URL: https://example.com/redirect/path http://example.com/path/to/file.ext https://example.com/redirect/path

How can I redirect the root of the webserver to a specific directory

Typically, this is better to configure this sort of redirect on your real servers, however you can utilize Header Modification to achieve the same result.

  1. Create a rule in Rules & Checking > Content Rules
  2. Use the following settings for your rule Rule Name: Rewrite_Root Rule Type: Modify URL Match String: ^/$ Modified URL: /redirect/to
  3. Navigate to your virtual service
  4. Under Advanced Properties select Show Header Rules
  5. Apply the Rewrite_Root rule to the Request Rules

By matching '/' and rewriting it to the desired value, you can force requests to a certain resource or directory.

I can’t find the setting for Not Available Redirection

Not Available Server and Not Available Redirect are mutually exclusive options. Both are ways of handling situations which would otherwise result in a downed virtual service. Not Available Server sends all traffic to that server without checking its health. Not Available Redirect instead replies to incoming requests with an error code and redirect URL or error message. These are two options for handle the same situation, but they cannot be used in conjunction. To enable the 'Not Available Redirection Handling' clear the 'Not Available Server' address and hit set. When the page refreshes, 'Not Available Redirection Handling' will be directly above it.

If you are still having trouble locating this setting, please confirm that the service type is set to HTTP/HTTPS. Other types of service are unable to perform redirection because it relies on specific HTTP functionality.

What is Port Following and how can I set it up?

Port following is set when two services need to share persistence records. Typically this is done for HTTP and HTTPS services so users maintain a server session regardless of whether they connect securely. This is explained in our manual in Section 4.6 and 16.7.

Port Following does have several requirements:

  • The Virtual Services must be on the same IP
  • The Virtual Services must have the same set of Real Servers
  • The Virtual Services must be using the same persistence options

After meeting these conditions, there will be an option under Advanced Properties for Port Following. Be sure to set this on both services to ensure that port following is done bidirectionally.