1. Kemp Support
2. Knowledge Base
3. Routing and Switching

How to configure Kemp LoadMaster Global Network Options

Updated: July 14, 2023 20:23

The purpose of this document is to outline the Global Network Options available on the LoadMaster's Web User Interface (WUI), and why you would need to change or enable these options. The described options are located on the WUI via System Configuration > Miscellaneous Options > Network Options:

 

Enable Server NAT

This option allows the LoadMaster to NAT connections sourcing from the Real Servers, on route to the Internet. After setting Enabled Server NAT globally, the Use Address for Server NAT checkbox will appear on each Virtual Service under Standard Options:

By default, the LoadMaster will NAT Real Server connections to the IP of the interface designated to reach the Internet. If using HA, the Shared IP of the interface facing the Internet will be the NATed IP Address. If the same Real Servers are configured on multiple Virtual Services, with Server NAT enabled, then connections to that respective Virtual Service will be NATed based on the destination port, to that Virtual Service's IP Address.

This option is most useful for services such as SMTP, when the LoadMaster is in a public domain and when the service requires a reverse DNS check to see if the Source IP Address sent from the LoadMaster is the same as the Mail Exchange (MX) record of the sender.

 

Connection Timeout (secs)

Sets the time (seconds) that a connection can be idle before it is closed. This is independent from the Persistence Timeout value set on the Virtual Service, when Persistence is enabled. The allowed values are: 0, 60-86400. By default, this is set to 660 seconds, while setting the value of 0, will default back to 660 seconds. The value set globally will not override any pre-existing, manually configured Idle Connection Timeout values, that were set under Standard Options on individual Virtual Services.

The reason for altering this option is to change the default Idle Connection Timeout for Virtual Services:

It may be required for Idle connections to remain active, without closing for some services such as Remote Desktop or Web services with payment checkouts for example.

 

Enable Non-Local Real Servers

When adding a Real Server to a Virtual Service and you receive the error message "Real Server not on available network", this means that the Real Server IP you are trying to add does not belong to a network that has been configured on one of the LoadMaster's interfaces. This is a Non-Local Real Server and will require the global Enable Non-Local Real Servers option to be enabled.

A Non-Local Real Server is one that resides on a network that is not local to the LoadMaster, when the LoadMaster does not have an arm/network interface configured in the Real Server's network. The LoadMaster will use its Global Default Gateway to communicate with the Non-Local Real Server instead. Hence, the appropriate routing between the LoadMaster's Global Gateway and the Real Server's network must be in place beforehand.

When adding a Non-Local Real Server to a Virtual Service, you will now see a checkbox labelled Allow Remote Addresses:

Enable this checkbox first, and then proceed to add your Non-Local Real Server IP Address as normal. Enabling Non-Local Real Servers prevents the need to configure multiple local interfaces on the LoadMaster, for the respective Real Server networks.

 

Enable Alternate GW support

When disabled, the Global Default Gateway will be set to eth0 by default. To allow another interface to be used as the Default Gateway, the global option (Enabled Alternate GW support) needs to be enabled first. After enabling this option, you will now see the Use for Default Gateway checkbox appear on all interfaces on your LoadMaster:

Once you select a new interface as the Default Gateway, you will be automatically directed (as of firmware version 7.2.41.1 and greater) to configure an new Default Gateway IP Address for the new interface network. On older firmware versions, you may lose WUI access if the appropriate routing to the new interface is not pre-configured on the network level. Local access (using a Client on the new interface's network, to connect to the new interface's IP directly, with no need to be routed over a Gateway) may be required. Please see this document for allowing Administrative WUI Access over multiple interfaces: Allow Administrative WUI Access

This option may be required if a migration of interfaces is desired, especially involving the migration of the management interface, where the current Global Default Gateway resides. For more information on Interface & WUI Migration, please see this Knowledge Base document: Migrating The WUI And Interfaces

 

Enable TCP Timestamps

This option will instruct the LoadMaster to include a Timestamp in the SYN of a TCP connection to the Real Servers. 

If it is required to know the round trip time of the TCP packets for troubleshooting, enabling Timestamps will help achieve this. However, be aware of the small security risk of using Timestamps, such as estimating the up-time of a Real Server, to determine whether security patches that require a reboot have been applied or not.

This should be disabled by default and not enabled, unless instructed by a KEMP Support Engineer for troubleshooting purposes.

 

Enable TCP Keepalives

This option will be enabled by default on newer firmware versions. It is designed to improve the reliability of long lived TCP connections such as SSH. The LoadMaster will use TCP Keepalives to check if a Client with an open TCP connection is still active or has possibly failed. This option is normally not required for HTTP/HTTPS connections.

Keepalives are non-invasive, and can be enabled without risk. However, be aware that extra network traffic is generated by this option. If you require any long lived TCP connection to remain active, with the connection socket remaining open, then TCP Keepalives are recommended.

 

Enable Reset on Close

When enabled, this option will allow the LoadMaster to close a TCP connection by sending a TCP RESET, instead of the conventional TCP handshake close method [FIN, ACK].

This may be required to close a TCP connection more swiftly, by not waiting for the final confirmation FIN,ACK from the Client or Real Server.

 

Subnet Originating Requests

This is the global option for enabling Subnet Originating Requests (SOR), on all configured Virtual Services and/or Sub Virtual Services:

The purpose of this setting is to change the Source IP Address of the connections between the LoadMaster and the Real Servers. When enabled, SOR uses the IP Address of the LoadMaster (Shared/Management IP in HA mode configurations), that is set on the interface that the Real Server is reachable on.

For example: the Real Server is configured on the same subnet/network as eth1 on the LoadMaster. With SOR enabled, the server will see packets sourcing from the eth1 Interface IP Address, if the LoadMaster is in single mode.  If the LoadMaster is in HA mode, the Real Server will see packets sourcing from the HA Shared/Management IP Address.

SOR is normally required in two-armed configurations, where the Virtual Service is on a different network to the Real Server. This can help prevent back-end Asymmetric Routing. For more information on SOR, please see this Knowledge Base document: Subnet Originating Requests

 

Enforce Strict IP Routing

Enabling Enforce Strict IP Routing operates in a similar way to the Packet Routing Filter option under System Configuration > Network Setup > Packet Routing Filter:

It would only be required to enable Enforce Strict IP Routing if there was a desire to only allow IP frames to be received from a host (a Real Server for example) over an interface on the LoadMaster, where the initiating connection was originally made.

For example, a connection to a Real Server from the LoadMaster is made over interface 1 (eth0). With Enforce Strict IP routing enabled, response IP frames returned from the same Real Server that the connect will only be accepted on eth0.

 

Handle non HTTP Uploads

The LoadMaster has been optimized with HTTP workloads in mind. Enabling this option will allow non HTTP uploads to work correctly. For example, FTP uploads may require this option to be enabled. 

 

Enable Connection Timeout Diagnostics

By default, this option has been disabled to prevent excess logs to be generated on the LoadMaster.

When troubleshooting any potential Connection Timeout issues on the LoadMaster, enabling this option would add more diagnostic information about the Timed-Out Connection to the System Logs. Only enable this option upon request from a KEMP Support Engineer.

 

Legacy TCP Timewait handling

Enabling this option will revert back to the legacy mode of reusing TCP Timewait connections. This restores the default settings of tcp_tw_recycle and tcp_tw_reuse. The new method of reusing TCP Timewait connections has been optimized for systems with a large number of connections. Hence, it is normally not recommended to enable Legacy TCP Timewait handling, unless instructed by a KEMP Support Engineer.

 

Enable SSL Renegotiation

The setting is enabled by default on newer firmware versions, and enables the LoadMaster to permit Clients to automatically renegotiate during an SSL handshake, in the event of a timeout or error occurring. Disabling this option will cause the SSL connection to terminate, if a renegotiation is requested by the Client.

 

Force Real Server Certificate Checking

By default, the LoadMaster will not check the SSL Certificate provided by the Real Server when traffic is being re-encrypted between LoadMaster and Real Server. Enabling this option, will force the LoadMaster to verify the SSl Certificate on the Real Server, before establishing a successful SSL connection. This may cause a slowdown in SSL connections being established under high traffic conditions.

 

Size of SSL Diffie-Hellman Key Exchange

This option dictates the strength of the shared key to be generated between the Client and the LoadMaster, using the Diffie-Hellman Key Exchange method for all SSL transactions on the LoadMaster. Currently, the highest configurable key size is 2048 bits (2k keys). Selecting the larger key size will improve security, but may have a negative impact on performance under high SSL traffic loads.

 

Use Default Route Only

This setting works best in conjunction with a Default Gateway configured on the Virtual Service under Advanced Properties. Use Default Route Only is a means of overriding the LoadMaster's Default Routing Metric Order Preference. It is important to know that the LoadMaster's Routing Metric Order Preference by default is a follows:

      0. Locally Connected Interface

      1. Static/Additional Routes (If defined)

      2. Default Gateway assigned to a Virtual Service (If defined)

      3. Global Default Gateway

When Default Route Only is enabled, and a Default Gateway has been added to a Virtual Service, local traffic will no longer be routed out their respective local interface on the LoadMaster (as per metric 0 above). Local traffic (as well as non-local traffic) will now be forcefully routed out the Default Gateway set on the Virtual Service:

Example 1 - Use Default Route Only disabled:

For the purpose of this example, I will use a two-armed setup involving a Client is on the eth0 network (192.168.0.0/24), with the Virtual Service and Real Server on the eth1 network (10.0.0.0/16). Note: the same applies to a one-armed setup. With Default Route Only disabled and the Default Gateway for the eth1 network assigned to the Virtual Service, the response from the server returns to the LoadMaster on eth1, and then the response from the LoadMaster back to the Client will be routed out eth0 (the local interface connected to the Client).

Example 2 - Use Default Route Only enabled:

With the same layout as described in Example 1 above, except this time, Default Route Only is enabled, and with the Default Gateway of the eth1 network configured on the Virtual Service, the return traffic to the Client will no longer be routed over eth0 (the local interface of the Client). It will now be routed out the eth1 Gateway, as specified on the Virtual Service.

This option may be required to prevent potential Asymmetric Routing or to force all response traffic back out to a certain gateway for security/routing purposes. As you may have noticed from the examples above, enabling Default Route Only has an implication on the LoadMaster's preferred routing metrics.

When troubleshooting, and you notice that you cannot access your Virtual Service from a certain Client or Network, a likely cause is the routing has not been configured correctly. Enabling or disabling Use Default Route Only, along with assigning a Default Gateway to your Virtual Service could be a potential solution.

 

HTTP(S) Proxy

A HTTP(S) proxy can be specified here, where required to do so. When configured, all outbound response HTTP/HTTPS traffic will be sent to this proxy from the LoadMaster. The current supported format for enabling this option is: ipaddress:port.

---

Comments

---

---

---