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 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	Virtual Service 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 Virtual Service

2. Virtual Service 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 Virtual Service, 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 Virtual Service

2. Virtual Service 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 Virtual Service 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 Virtual Service to the Real Server
• The Real Server sees traffic originating from the 10.0.0.15/24 Virtual Service 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 Virtual Services, 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 Virtual Service address.

4 Use Default Route Only

By default, the LoadMaster sends traffic directly to a known network. This can cause asymmetric routing. A common scenario is related to firewall security.

In this scenario, the traffic arrives from the external firewall, and goes through the LoadMaster to the Real Servers. This can cause a security concern because if the LoadMaster is vulnerable, then someone could access the Real Servers - think of this as a "man in the middle attack". In theory, there is a single point of security failure.

The alternative is to use the default route only option. This forces traffic to be sent to the default gateway, even though the LoadMaster knows how to route the traffic to the local network.

In the scenario with default route enabled, it is up to the firewall to distinguish between legitimate and illegitimate traffic using SNORT and Web Application Firewall (WAF) rules. However, a firewall should have a better system for dealing with this as it is designed from the ground up.

In the diagram above, the option Use Default Route Only option (System Configuration > Network Options) is enabled and a default gateway is set on the Virtual Service. Traffic which is connecting to the Virtual Service on eth0 is not passed to eth1 directly but instead is being forwarded to that Virtual Service's default gateway (a DMZ Firewall in this scenario).

From here, the default gateway (DMZ firewall) forwards the traffic to the LoadMaster on eth1. After this, the LoadMaster continues handling the traffic, that is, from eth1 to the Real Server. The return traffic follows the same path.

Initiating traffic:

Client > External Firewall > Virtual Service (eth0) > Virtual Service default gateway (DMZ firewall) > eth1 > Real Server

Returning traffic:

Real Server > eth1 > Virtual Service default gateway (DMZ firewall) > eth0 > external firewall > 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 21 June 2022.