SysPad › Lessons › networking lessons › Gateway Load Balancer

How Gateway Load Balancer works

Transparent L3 load balancer that fans traffic across a fleet of virtual security appliances (firewall, IDS/IPS) over GENEVE. Adds an inspection hop, not app latency. Billed hourly + per GLCU-hour.

Your security team wants every packet run through their favourite firewall appliance, but those appliances need to be scaled, health-checked, and slotted into the network without rewriting anyone's routes. The Gateway Load Balancer is the one device that does both jobs: a transparent gateway and a load balancer for a fleet of inspection appliances.

What you will learn

What problem does GWLB solve that an ALB or NLB does not?
How does it insert appliances into the path without changing your app addressing?
What is GENEVE encapsulation and why does it matter for inspection?
Why must a flow stick to one appliance, and how does GWLB ensure that?

Scaling inspection appliances is hard

Virtual firewalls, IDS/IPS, and deep-packet-inspection appliances need to see traffic, but running a fleet of them means load-balancing across them, health-checking them, and getting traffic to flow through them transparently. A normal ALB/NLB terminates connections; that is not what an inline inspector wants.

A transparent bump in the wire

GWLB operates at layer 3. You point your route tables at a GWLB endpoint, and traffic transparently detours through the appliance fleet and back, with no change to source or destination addressing. The apps do not know an inspector is there.

⚓ Centralised security inspection in a hub VPC, traffic between VPCs or to the internet forced through Palo Alto / Fortinet / Check Point appliances, and compliance-mandated DPI.

GENEVE: hand the appliance the real packet

GWLB and the appliances speak GENEVE encapsulation on port 6081. The original packet is wrapped and sent to a chosen appliance, which unwraps it, inspects the real, unaltered packet, and returns it. That preservation is exactly what an IDS or firewall needs to make a verdict.

Flow stickiness for stateful appliances

A stateful firewall tracks a connection's state, so it must see both directions of the same flow. GWLB keeps flow stickiness: a given 5-tuple flow always lands on the same appliance, so its connection state stays consistent even as the fleet scales.

Flashcards

What is GWLB built to deploy and scale?: A fleet of third-party network appliances (firewalls, IDS/IPS, DPI), load-balanced and health-checked inline.
How does GWLB insert appliances without changing app addressing?: It is a transparent layer-3 bump-in-the-wire: route tables send traffic via a GWLB endpoint, through the fleet, and back.
What does GWLB use GENEVE (port 6081) for?: To encapsulate traffic to appliances so they receive and inspect the original, unaltered packet.
Why does GWLB keep a flow on the same appliance?: So a stateful appliance sees both directions of the flow and its connection state stays valid.
How is GWLB different from an ALB/NLB?: ALB/NLB balance traffic to your app servers and often terminate connections; GWLB transparently routes traffic through inspection appliances and back.

Sources

Open the SysPad canvas · Official Gateway Load Balancer documentation