BIG-IP integration with Azure Gateway Load Balancer

Introduction

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.

The Challenge

Many organizations face challenges with Azure network operations, like:

  • setting up High Availability (HA) can be a learning curve for admins of 3rd party appliances in Azure
  • using User Defined Routes (UDR's) to direct traffic to a network appliance can be difficult for some organizations, especially updating at scale
  • dealing with multiple VNets across multiple regions and routing traffic between them can add operational overhead
  • requiring Source NAT (SNAT) can be a deal-breaker for app owners, but architecting for flow symmetry without SNAT can require serious know-how

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.

No SNAT

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.

Enter Gateway Load Balancer

The gateway load balancer is aimed at load balancing firewalls, routers or other network appliances. Some high-level benefits:

  1. It's transparent. Source and Destination IP addresses are unchanged when traffic traverses the gateway load balancer, via VXLAN tunnels to backend pool members. Your firewall admin can now set up policies without worrying about Source or Destination NATs.
  2. Flow symmetry. The load balancer will ensure that response traffic hits the same device on the return path as it did on the request path. This means you can run multiple standalone or Active/Active appliances without using SNAT or UDR's to ensure flow symmetry.
  3. UDR's are not required, because traffic reaches the gateway load balancer in one of two ways:
  4. Either a regular, external load balancer is updated to send traffic via the gateway load balancer before forwarding to it's backend pool, or,
  5. If the VM is not behind an Azure Load Balancer, the VM's NIC is updated so that traffic traverses the gateway load balancer before it receives traffic.
  6. Traffic across VNets and Regions is supported. You can target a gateway load balancer from a regular load balancer that is in a different VNet, or a different region. UDR's are not used, and VNet peering is not required for this traffic flow.

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.

Example scenario

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.

 

 

Demo

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.

 

Published Nov 02, 2021
Version 1.0
Azure
BIG-IP
cloud
security

Was this article helpful?

3 Comments

Sort By
  • ChrisGordon's avatar
    ChrisGordon
    Icon for Nimbostratus rankNimbostratus
    Jul 28, 2022

    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. 

    Respectfully,

    Chris Gordon

  • antonym's avatar
    antonym
    Icon for Nimbostratus rankNimbostratus
    Feb 16, 2023

    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.

  • MichaelOLeary's avatar
    MichaelOLeary
    Icon for Employee rankEmployee
    Jun 22, 2023

    Hi antonym ,

    Sorry, I see your question is from February but I wasn't notified of it, so I am only just coming across it. The answer to your question is a little complex, but you actually can proxy traffic (ie, use LTM functionality) but you must use another network interface to send that proxied traffic out from. Then after the pool member's response, ensure that the traffic "returns back down the VXLAN tunnel" as you put it, without changing the 5-tuple (src ip, dest ip, src port, dest port, protocol).

    It's complicated but it does work. That said, I just tell people to use the GWLB when they want ASM/AFM functionality, because that's what it's intended for. Hopefully that makes sense and sorry this answer comes so late!