UDP
Use LVS in NAT mode to load balance UDP services at layer 4. In this scenario, responses from servers flow through HAProxy ALOHA (i.e. not Direct Server Return).
With Network Address Translation (NAT), HAProxy ALOHA changes the destination IP address and the client's source IP address in the packets before relaying them to the backend server. The destination IP is converted from the public IP on which HAProxy ALOHA listens to the backend server's private IP. The client's source IP is converted to be the HAProxy ALOHA appliance's IP. This leads to the least amount of configuration on the backend servers, which receive traffic on their private addresses, and simply return traffic to the source IP, which is that of the HAProxy ALOHA appliance. HAProxy ALOHA reverses these addresses on the return trip to the client.
This method is supported by both Linux and Windows backend servers. Backend servers can keep the network's external gateway as their default gateway. Disadvantages include that it reduces the number of connections that HAProxy ALOHA can support, due to needing to use more ports.
Optionally, you can enable NAT for the destination IP only and then set HAProxy ALOHA to be the default gateway on the backend server. That accomplishes the same thing and would use fewer ports on HAProxy ALOHA, at the cost of a slightly more complex setup on the backend server (i.e. needing to change the default gateway).
Traffic flow
The client connects to your application at the configured public IP address. HAProxy ALOHA listens at that address and receives the packets.
The packet's destination IP address is translated from HAProxy ALOHA's public IP to the private IP of one of the backend servers. Simultaneously, the packet's source IP addresses are translated from the client's IP to HAProxy ALOHA's IP address.
The backend server accepts the request to its IP.
The backend server sends its response to HAProxy ALOHA because its address is set as the source IP in the packet.
HAProxy ALOHA performs the reverse NAT before relaying the response to the client.
Enable Destination NAT
We will configure LVS so that it translates the destination IP from the public IP on which HAProxy ALOHA listens to the backend server's private IP.
-
In the web UI's LB Layer 4 tab, add the
mode natdirective to your existing configuration, and apply your changes.director web 10.0.0.3:8000 UDP balance leastconn mode nat server web1 10.0.0.20:8000 weight 10 check
Enable Source NAT
We will create iptables NAT rules to translate the client's source IP to the HAProxy ALOHA appliance's IP.
-
In the NAT tab, click + to add a new NAT rule.
-
Select the following values in the New Rule area, depending on how many network interfaces are attached to HAProxy ALOHA.
-
One network interface
--------+-------- 10.0.0.0/24, VIPs, backend servers | | eth0 +---------+ | | | ALOHA | | | +---------+Field
Description
IN
Inbound network interface
OUT
Outbound network interface, the same as the inbound interface
Protocol
UDP
-
Two network interfaces
--------+-------- 10.0.0.0/24, VIPs | | eth0 +---------+ | | | ALOHA | | | +---------+ | eth1 | --------+-------- 10.0.3.0/24, backend serversField
Description
IN
Inbound network interface
OUT
Outbound network interface, different from the inbound interface
Protocol
UDP
-
-
Enter the following values in the Before area.
Field
Value
Example
Source
Blank
Source port
Blank
Destination
VIP address
10.0.0.3
Destination port
UDP port or range
8000, or 50000-51000
-
Enter the following values in the After area.
Field
Value
Example
Source
VIP address
10.0.0.3
Source port
Blank
Destination
Blank
Destination port
Blank
-
Check your configuration, then apply it.
Enable LVS's connection tracking
NAT relies on the connection tracking information so that it can translate all of the packets in a session in the same way.
-
In the Services tab, click LVS setup.
-
Enable connection tracking through the
conntrackkeyword.service lvs ############ Linux Virtual Server, layer 3/4 load balancing conntrack Apply and reload the LVS service.
Next up
TCP