on 02-Nov-2021 09:00
Microsoft just announced the Gateway Load Balancer. This is a new load balancer sku to go along with the existing types of Basic and Standard, however, this is aimed at sending traffic to transparent network devices for in-line traffic inspection. This article will overview the gateway load balancer and explain how F5 BIG-IP can integrate for transparent traffic inspection. Check out MS's blog too.
Many organizations face challenges with Azure network operations, like:
Finally, there's a very real skills gap between most Network/Security teams and Cloud teams. Often, a SecOps team member (eg, firewall admin) just wants to manage a firewall, without needing to know about Azure networking. Likewise, the CloudOps team want to send traffic through the firewall without having to alert the SecOps team for every new application added.
With Azure's Basic and Standard load balancer types, it is possible to achieve much of this and I've blogged about this before. But things get complicated quickly with advanced scenarios. The Gateway load balancer makes load balancing network appliances much easier.
It's important to remember that this is aimed at network devices that are inspecting but not proxying traffic. I.e., src and dst IP and port should be preserved when traffic traverses BIG-IP in this scenario, so SNAT is not supported. Think of transparent firewalling as a good use case here.
The gateway load balancer is aimed at load balancing firewalls, routers or other network appliances. Some high-level benefits:
One last important point I'll make: this load balancer type is aimed at solving for North-South traffic, not East-West. I.e., your typical use-case will be for inbound traffic from Internet to your app servers on your Azure VNet. Put your app servers behind a public-facing load balancer, update that load balancer to reference the gateway load balancer, and you're good to go! No need to ask the firewall or F5 admin to configure a new application for you, or a new public IP on their device, etc.
In this scenario we have a web app that is internet-facing. We want to protect the web app from attacks by having the traffic traverse BIG-IP Advanced WAF (AWAF). The gateway load balancer is configured to allow all traffic inbound to the BIG-IP VE's, where security policies are applied. So we deploy a public-facing Azure Load Balancer, configure the load balancer with an attribute referencing the gateway load balancer, and watch as traffic from internet clients is routed via the Advanced WAF devices in transit to the app servers.
A basic demo of this is hosted on GitHub, if you would like to deploy this yourself or see more details. The BIG-IP's will require VXLAN tunnels configuration, VLAN groups, FDB entries, and ARP records. This is to integrate with the VXLAN requirements of the gateway load balancer. See the demo on GitHub here.
Excellent article Michael! Gateway Load Balancer will be a game changer for F5 Big IP appliances in Azure. A lot of customers I work with struggle with management of routes and load balancers but this should greatly simplify the way they use NVAs.
Very useful Michael thanks. I think you state it when you call this use-case "transparent firewalling" but just to check... The Gateway LB is of no use if you want to use the big-ip as a load balancer (LTM) for your application - is this correct? It seems like the idea is that the GLB is a transparent "hop" between an Azure public load balancer front-end IP and back-end pool. So the big-ip could be used for ASM/AFM functions, but not for LTM as the only option is for the traffic to return back down the VXLAN tunnel to the Azure LB, which then onward routes to the application.