Why we may need multiple default gateways?
Nowadays, Application Delivery controllers (aka Load-Balancers) become the entry point for all the applications hosted in a company or administration.
That said, many different type of population could access the applications:
* internal users from the LAN
* partners through MPLS or VPNs
* external users from internet
On the other side, applications could be hosted on different VLANs in the architecture:
* internal LAN
* external DMZ
The diagram below shows the « big picture » of this type of architecture:
Routing in the Linux network stack
I’m not going to deeply explain how it works, sorry… It would deserve a complete blog post 🙂
That said, any device connected on 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 which 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 HAProxy can help in such situation??
Users access applications through a 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 manager would say that it is absolutely unsecure to plug a device in multiple DMZ or VLANs. They are right. But usually, this type of company’s business is very important and they can affoard 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 Loadbalancer. Just update the content to match your Linux distribution configuration syntax.
The configuration is also related to the diagram above.
In your ALOHA, go in 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:
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 website 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 internet, HAProxy can let the kernel to 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.
HAProxy configuration for Sharepoint 2010 or 2013
This service is used by MPLS/VPN users and internal users.
frontend ft_exchange bind 10.0.1.4:443 interface eth1 bind 10.0.2.4:443 interface eth2 [...]
The responses to MPLS/VPN users will go through eth1 default gateway 10.0.1.1 while the one for internal LAN users will use the default gateway configured on eth2 10.0.2.1.