NAT mode considerations

DNAT Mode Considerations

Layer 4 DNAT mode requires Real Server return traffic to pass back via the load balancer. This is achieved by setting each Real Server’s default gateway to be the load balancer. For a multi-node cluster, a floating IP address should be used to allow the gateway to "float" (move) between appliances should a failover occur.

Whilst DNAT mode is fairly straight forward, certain points need to be considered.

DNAT Mode Potential Issues

By default the Real Servers won’t be able to access the Internet through the new default gateway (except when replying to requests made through the external VIP).
Non-load balanced services on the Real Servers (e.g. RDP for management access to Windows servers) will not be accessible since these have not been exposed via the load balancer.

Enabling Access to non Load Balanced Services

If you want non load balanced services on your Real Servers to be accessible from the external subnet, options include:

Configure a layer 4 SNAT mode or Layer 7 (proxy mode) Virtual Service listening on the relevant service port(s) and add the required Real Server leaving the Real Server Port field blank.
Configure a DNAT mode Virtual Service listening on the relevant service port(s) and add the required Real Server leaving the Real Server Port field blank. The Real Server’s default gateway must be the load balancer.

One-Arm (Single Subnet) DNAT Mode

Normally the VIP is located on a different subnet to the Real Servers. However, it is possible to perform DNAT mode load balancing on a single subnet where the VIP is brought up in the same subnet as the Real Servers. For clients located on this subnet, return traffic would normally be sent directly to the client bypassing the load balancer which would break DNAT mode. To address this, the routing table on the Real Servers must be modified to force return traffic to pass via the load balancer. The sections below explain how routing must be modified for Windows hosts and Linux hosts.

Route Configuration for Windows Servers

To rectify this issue for Windows servers, a route must be added to each Real Server that takes priority over the default Windows routing rules. This is a simple case of deleting the default On-link route and adding a permanent route via the load balancer using the following commands on each real server:

netsh interface ipv4 delete route 192.168.2.0/24 "LAN"
netsh interface ipv4 add route 192.168.2.0/24 "LAN" 192.168.2.21

Replace "192.168.2.0/24" with your subnet address, "192.168.2.21" with your load balancer’s IP address and "LAN" with the name of the interface on your server.

After running the above commands, reboot the server and check if the updated routing rules have remained. Depending on the specific version of Windows, it may be necessary to add the commands to a startup script. This is because under certain circumstances routing rules for on-link, directly accessible addresses can get reset to defaults after a reboot.

Verify routing rules using the following command:

netsh interface ipv4 show route

Route Configuration for Linux Servers

To rectify this issue for Linux servers, the local network route must be changed to a higher metric:

route del -net 192.168.2.0 netmask 255.255.255.0 dev eth0
route add -net 192.168.2.0 netmask 255.255.255.0 metric 2000 dev eth0

Ensure you specify your local subnet address.

Then we must ensure that local network access uses the load balancer as its default route:

route add -net 192.168.2.0 netmask 255.255.255.0 gateway 192.168.2.21 metric 0 dev eth0

Replace 192.168.2.0 & 255.255.255.0 with your local subnet address and replace 192.168.2.21 with the IP address of your load balancer.

Any local traffic (same subnet) is then handled by the manual route and any external traffic is handled by the default route (which also points at the load balancer).