1 Introduction

The Kemp LoadMaster has various routing-related options, such as transparency, Subnet Originating Requests (SOR), and Use Default Route Only.

When using the LoadMaster, you may experience different routing scenarios. The purpose of this document is to explain the different routing options and how routing can be managed inside a network.

The above network diagram shows an example standard two-armed setup:

• The client has an internal IP address of 192.168.1.x/24
• When it connects to the public site, the firewall will Network Address Translate (NAT) traffic from external networks to another IP address
• In this case, it will NAT the traffic to the 10.10.10.x/24 network
• The Virtual Service (VS) is on 10.10.10.12/24 (eth0 network)
• The Real Server is on 10.15.15.100/24 (eth1 network)

Depending on transparency and SOR, the Real Server may see traffic originating from a different IP address.

Transparency	Subnet Originating Requests	Real Server sees
Disabled	Disabled	VS address
Disabled	Enabled	LoadMaster Real Server-side interface address
Enabled	Disabled	Client IP address
Enabled	Enabled	Client IP address

If transparency is enabled, SOR does not have any effect on the routing of traffic.

Health checks are always sent from the interface of the Real Server network.

1.1 Document Purpose

This document provides information on some of the routing features within the LoadMaster, such as transparency, SOR, and the Use Default Route Only option.

1.2 Intended Audience

This document is intended to be used by anyone interested in finding out more information about routing in the LoadMaster.

2 Transparency

Layer 4 is always transparent.

When using Transparency, there are some requirements that must be met:

• The Real Server needs to have the LoadMaster as the default gateway (shared IP address when High Availability (HA) is used).
• The clients cannot be on the same subnet as the Real Server.
• The option Use Address for Server NAT must be enabled in the Virtual Service Standard Options. If Subnet Originating Requests is enabled, the global Enable Server NAT must be enabled (System Configuration > Miscellaneous Options > Network Options).

Transparency cannot be used with non-local Real Servers.

The diagrams and text below explain why these requirements must be met.

For further information on transparency, refer to the Transparency, Feature Description.

2.1 Scenario 1 - The LoadMaster is Not the Default Gateway

In the diagram above, neither of the flows have the LoadMaster as the default gateway. To be transparent, the default gateway of the Real Servers must be the LoadMaster. This is true whether the network configuration is one-armed or two-armed.

If the LoadMaster is not the default gateway, there is no way to ensure that traffic passes back through the LoadMaster on the way from the server to the client.

If transparency is enabled and the LoadMaster is not the default gateway, the traffic flows in the following order:

1. Client to VS

2. VS to Real Server

3. Real Server to network default gateway

4. Network default gateway to client

The connection fails between the Real Server and network default gateway. This is due to asymmetric routing. The client gets a response from the default gateway and drops the connection because it expected a reply from the LoadMaster.

2.2 Scenario 2 - Clients in the Same Subnet as the Real Servers

Another requirement of transparency is that you must be browsing from a subnet other than that of the Real Servers. Again, it is to ensure that traffic passes in and out of the LoadMaster.

If you are on the same subnet as the Real Server, the return traffic simply goes directly to the client, instead of through the LoadMaster. As a result, the client expects to see traffic come from the IP address of the VS, but instead sees traffic coming from the IP address of the Real Server. When that happens, the client system ignores the traffic.

If transparency is enabled and the clients are in the same subnet as the Real Server, the traffic flows in the following order:

1. Client to VS

2. VS to Real Server

3. Return traffic from Real Server direct to client

The connection fails between the Real Server and the client due to the fact that the clients are in the same subnet as the Real Server.

This is due to asymmetric routing. The client gets a response from the Real Server and drops the connection because it expects a reply from the LoadMaster.

3 Subnet Originating Requests

When Subnet Originating Requests is enabled, the LoadMaster changes the originating IP address of the traffic. Normally, the traffic is seen being sent from the VS address. With SOR enabled, traffic is seen as being sent from the local interface address. This is needed in two-armed setups when SSL offloading is enabled.

The example diagram above is explained as follows:

• Traffic flows from the client to the VS to the Real Server
• The Real Server sees traffic originating from the 10.0.0.15/24 VS and replies using its default gateway
• The default gateway responds to the LoadMaster using the eth0 network 10.0.0.x/24
• With SOR enabled, the Real Server sees traffic originating from the eth1 interface (10.20.20.21) and replies directly to the LoadMaster

Kemp recommends enabling SOR by default when creating VSs, unless you require transparency.

Currently, SOR does not work with non-local Real Servers. If non-local Real Servers are being used with SOR, the Real Servers see traffic as originating from the VS address.

4 Use Default Route Only

In certain situations, it may be necessary to force the LoadMaster to always respond to certain client requests through an alternate gateway. This typically happens in a two-armed network configuration when a client that resides on LoadMaster's Real Server network connects to a VS using the VS IP address.

Because the LoadMaster 'knows' the network on which the client IP address resides, by default it attempts to respond to the client directly over the Real Server network, rather than responding through the gateway associated with the VS IP. On the client side, you will see broken connections; when the client sees the response on the local Real Server network, it rejects it because it is expecting a response from the VS IP (not the LoadMaster's IP on the local network).

The Use Default Route Only option (System Configuration > Miscellaneous Options > Network Options) enables you to work around this problem by getting the LoadMaster to use manually defined routes for specific clients instead of responding to them over directly connected networks.

Manual (or static) routes are defined on the System Configuration > Network Setup > Additional Routes page. For example, you have a client IP of 192.168.1.120 and it is sending requests to a VS IP of 172.16.0.30. In doing so, the client is routing the request through a firewall/gateway at 172.16.0.50, which sends the traffic on to the LoadMaster. In this case, you would add a route that specifies a client IP of 192.168.1.120 and a gateway of 172.16.0.50 so that the LoadMaster knows the 'correct' way to talk to this client.

By also enabling Use Default Route Only, the LoadMaster now honors the route you entered by sending traffic destined for the client at 192.168.1.120 through the gateway at 172.16.0.50, instead of using the Real Server network to talk directly to the client.

References

Unless otherwise specified, the following documents can be found at http://kemptechnologies.com/documentation.

Transparency, Feature Description

Last Updated Date

This document was last updated on 03 March 2022.