Application Delivery Controllers (Load Balancers) become the entry point for all the applications hosted in a company or administration. That said, many different types of populations could access the applications:
internal users from the LAN
partners through MPLS or VPNs
external users from the internet
On the other side, applications could be hosted on different VLANs in the architecture:
The diagram below shows the “big picture” of this type of architecture:
Routing in the Linux Network Stack
That said, any device connected to an IP network needs an IP address to be able to talk to other devices in its LAN. It also needs a default gateway to be able to reach devices that are located outside its LAN.
A Linux kernel can use a single default gateway at a time, but thanks to the metric you can configure many default gateways. When needed, the Linux Kernel will parse the default gateway table and will use the one with the lowest metric. By default, when no metric is configured, the kernel attributes a metric 0. Each metric must be unique in your Kernel IP stack.
How Can HAProxy Help?
Users access applications through an HAProxy bind. The bind can be hosted on any IP address available or not (play with your sysctl for this purpose) on the server.
By default, the traffic comes in HAProxy through this bind and HAProxy let the kernel choose the most appropriate default gateway to forward the answer to the client. As we’ve seen above, the most appropriate default gateway from the kernel point of view is the one with the lowest metric usually 0.
That said, HAProxy is smart enough to tell the kernel which network interface to use to forward the response to the client. Just add the statement interface ethX (where X is the id of the interface you want to use) on HAProxy bind line. With this parameter, HAProxy can force the kernel to use the default gateway associated to the network interface ethX if it exists, otherwise, the interface with the lowest metric will be used.
From a security point of view, some security managers would say that it is absolutely unsecure to plug a device into multiple DMZ or VLANs. They are right. But usually, this type of company’s business is very important and they can afford one load-balancer per DMZ or LAN. That said, there is no security breach with the setup introduced here. HAProxy is a reverse-proxy and so you don’t need to allow ip_forward between all interfaces for this solution to work.
I mean that nobody could use the loadbalancer as a default gateway to reach an other subnet bypassing the firewall…
Then only traffic allowed to pass through is the one load-balanced!
The configuration below applies to the ALOHA load balancer. Just update the content to match your Linux distribution configuration syntax.
The configuration is also related to the diagram above.
In your ALOHA, go to the Services tab, then edit the Network configuration.
To keep it simple, I’m not going to add any VRRP configuration.
service network eth0 ########## eth0. auto on ip address 10.0.0.2/24 ip route default 10.0.0.1 service network eth1 ########## eth1. auto on ip address 10.0.1.2/24 ip route default 10.0.1.1 metric 1 service network eth2 ########## eth2. auto on ip address 10.0.2.2/24 ip route default 10.0.2.1 metric 2 service network eth3 ########## eth3. auto on ip address 10.0.3.2/24 ip route default 10.0.3.1 metric 3 service network eth4 ########## eth4. auto on ip address 10.0.4.2/24 ip route default 10.0.4.1 metric 4
The routing table from the ALOHA looks like this:
default via 10.0.0.1 dev eth0 default via 10.0.1.1 dev eth1 metric 1 default via 10.0.2.1 dev eth2 metric 2 default via 10.0.3.1 dev eth3 metric 3 default via 10.0.4.1 dev eth4 metric 4
HAProxy configuration for Corporate websites or ADFS proxies
These services are used by internet users only.
frontend ft_www bind 10.0.0.2:80 [...]
No need to specify any interface here, since the traffic comes from the internet, HAProxy can let the kernel use the default gateway which points in that direction (here eth0).
HAProxy configuration for Exchange 2010 or 2013
This service is used by both internal and internet users.
frontend ft_exchange bind 10.0.0.3:443 bind 10.0.2.3:443 interface eth2 [...]
The responses to internet users will go through eth0 while the one for internal LAN users will use the default gateway configured on eth2 10.0.2.1.
Links:Subscribe to our blog. Get the latest release updates, tutorials, and deep-dives from HAProxy experts.