In this blog post, we're exploring AWS Gateway Load Balancer, commonly known as GWLB. We'll get to grips with what it is and how it works. To make it easier to understand, we're using Palo Alto Firewalls as our hands-on example. If you're keen on learning how to bring the best of AWS and Palo Alto together, you've come to the right place. Let's get started.
What is a Gateway Load Balancer (GWLB)?
Gateway Load Balancer helps you easily deploy, scale, and manage your third-party security appliances. It gives you one gateway for distributing traffic across multiple virtual appliances while scaling them up or down, based on demand. You can use third-party virtual appliances such as next-generation firewalls (NGFW), web application firewalls (WAF), and intrusion detection and prevention systems with GWLB.
In simpler terms, let's say you want to inspect both East-West and Egress traffic in your AWS setup. First, you'd put your Next-Generation Firewalls (NGFWs) in a special Security VPC. Now, here's where Gateway Load Balancer (GWLB) makes your life easy. All you do is place these NGFWs behind the GWLB and then point all your VPC route tables to the firewall endpoints (via TGW). We'll dive deeper into this later.
At the core of all this is the Transit Gateway, or TGW. You attach all your VPCs and your Security VPCs to the TGW, and it handles the routing between them.
Suresh Vina
Gateway Load Balancer TL;DR
GWLB listens for all IP packets across all ports and forwards traffic to the target group that's specified in the listener rule. It maintains the stickiness of flows to a specific target appliance using a 5-tuple. The Gateway Load Balancer and its registered virtual appliance instances exchange application traffic using the GENEVE protocol on port 6081.
Gateway Load Balancers use Gateway Load Balancer endpoints (GWLBe) to securely exchange traffic across VPCs. A Gateway Load Balancer endpoint is a VPC endpoint that provides private connectivity between virtual appliances in the Security VPC and application servers in the consumer VPC. You deploy the Gateway Load Balancer in the same VPC as the virtual appliances. You register the virtual appliances with a target group for the Gateway Load Balancer.
Traffic to and from a Gateway Load Balancer endpoint is configured using route tables. Traffic flows from the consumer VPC (app/db VPC) over the Gateway Load Balancer endpoint to the Gateway Load Balancer in the Security VPC, and then returns to the VPC.
The flow would be - Source > TGW > GWLBe > GWLB > Firewall > GWLB > GWLBe > TGW > Destination
Using a Real-World Example to Understand GWLB
Throughout this blog post, we'll focus on this specific scenario to show you how it all works. We have two VPCs, "database-vpc" and "application-vpc," and we want to inspect the traffic between them and any egress traffic. All of this traffic will go through our third "security-vpc" where the firewalls and GWLB ednpoints are deployed. This example will help us understand how to set up and use AWS Gateway Load Balancer with Palo Alto Firewalls.
When it comes to explaining this setup with two AZs, putting everything on one diagram would make it way too messy. So, we're going to split it up. First, we'll focus on a diagram that explains how the traffic routes from the "app-vpc" and "db-vpc" all the way to the TGW. This will help us get the basics down.
In the second diagram, we'll dig into how the Gateway Load Balancer (GWLB) interacts with the Palo Alto VM-Series firewall. This way, we can dive into the specifics without overwhelming you.
A few things to Consider
1. Management Interface Swap
In a typical setup, the GWLB uses a single listener and target group. We've chosen to specify the GWLB target as an instance (VM-Series Firewall) rather than an IP address, given that the IP could change if we redeploy. When we set the target as an instance, the GWLB directs traffic to the instance's first interface, which is, by default, the firewall's management interface. However, for our use case, we need the first interface to be a dataplane interface. So, we enable the swap-interface option on the firewall to achieve this.
When you launch the firewall, you can either enter the mgmt-interface-swap=enable command in the User data field on the AWS management console or you can include the new mgmt-interface-swap operational command in the bootstrap configuration.
2. Number of Subnets for Security VPC
Next, let's talk about the number of subnets we'll need in our Security VPC. Ideally, we're looking at four separate subnets here. The first subnet is for the firewall management interface. This is where you'll handle all the settings, rules, and whatnot for your firewall.
The second subnet is for the firewall data plane interface and also where we'll place our Gateway Load Balancer Endpoints or GWLBe. This subnet takes care of the actual traffic flow.
The third subnet is for the TGW Network Interfaces. This is the subnet that talks to our Transit Gateway and helps in routing traffic to and from our Security VPC.
Last but not least, we'll also have a public subnet where we're going to place our NAT Gateway.
3. TGW Account
It's worth noting that if you prefer to keep things separated, you can create the Transit Gateway in a different AWS account. You can then use AWS's Resource Access Manager to share the TGW with other accounts, including those containing your consumer VPCs and Security VPCs.
4. Config and State
Firewalls operate independently of each other and don't share state information with each other. The Gateway Load Balancer makes sure that a single traffic flow sticks to the same firewall throughout its life. To keep the configuration in sync, it's a good idea to use Panorama for configuration management. Simply add all your firewalls to the same device-group, and they'll share the same config, preventing any configuration drift.
How does the Routing Work?
Alright, let's dive into the routing part of our setup. In both our "app-vpc" and "db-vpc," the default route in their route tables will point to our Transit Gateway (TGW). Speaking of TGW, it will have two route tables, one we'll call "spoke-rt" for our app and db VPCs, and the other "security-rt" for our Security VPC.
Now, both the app and db VPCs will be associated with the "spoke-rt," but we won't propagate the routes. This is important because if we did, then the two VPCs could talk to each other without going through the Security VPC, and we don't want that. But we will propagate routes into the Security VPC. This way, when traffic comes back to the TGW from the Security VPC, TGW knows exactly where to send it.
Back to our TGW route tables. The "spoke-rt" will have a default route pointing to our Security VPC attachment. This ensures the traffic moves from TGW to the Security VPC.
Gateway Load Balancer and Endpoints
Inside the Security VPC, we've got a few route tables. One of them is tied to the TGW network interfaces subnet, which we'll call "tgw-eni-rt" This route table points its default route to the Gateway Load Balancer Endpoints.
Now, let's jog our memory a bit. The traffic from our spoke-VPCs, whether it's the app or db VPC, first heads to the TGW. From there, TGW routes it to our Security VPC. Once the traffic lands in the TGW network interfaces (TGW-ENIs) inside the Security VPC, it checks out the route table tied to that subnet. In this case, the "tgw-eni-rt" route table directs the traffic towards GWLBe with its default route.
At this point, the GWLBe takes over. It sends the traffic to the Gateway Load Balancer (GWLB), which then forwards it to a healthy firewall, just like we've shown in the diagram. This just happens automatically and we don't have to manually setup any routing.
After the firewall inspection, the data goes back to the GWLB and then to the GWLB endpoint.
- If the destination is for the Internet (north-south), It's then sent to a NAT Gateway, where it's processed for Network Address Translation. Lastly, this packet is sent from the NAT Gateway to an Internet Gateway, and finally out to the Internet. For Egress, the route-table associated with the data-subnet (where we placed the GWLBe) will have a default-route pointing to the NAT gateway.
- If the destination is for another VPC or on-prem (east-west), GWLBe routes the traffic back to the TGW which then will be sent out to the appropriate destination. For East-West, the route-table associated with the data-subnet (where we placed the GWLBe) will have a route for the RFC1918 addresses that points to the TGW attachment.
TGW Appliance Mode and Asymmetric Routing
Let's imagine a scenario where Instance-A in AZ1 wants to send traffic to Instance-B in AZ2. The first thing it does is consult its own VPC route table, which tells it to send the data to the Transit Gateway. The TGW gets the traffic and checks its own route table to find the next-hop. In this case, it sends the traffic to the Security VPC.
Inside this Security VPC, the traffic lands on the TGW network interfaces, which have their own route table that points the traffic to the Gateway Load Balancer Endpoints, or GWLBe. Now, the GWLBe takes this traffic and forwards it to the actual Gateway Load Balancer. This Load Balancer sends the traffic to one of the healthy firewalls.
After the inspection, the data is sent back to the TGW. The TGW forwards it to the VPC attachment, where Instance-B resides. Finally, the data reaches the VPC route table in AZ2, which gets routed to its final destination, Instance-B.
When Instance-B in AZ2 wants to reply, the traffic first goes to the TGW. Here's where a problem can occur. By default, the TGW forwards this return traffic to its interface in the Security VPC in AZ2. Now, this puts the traffic in front of a firewall in AZ2, which has no clue about this session. As a result, the firewall drops the traffic. Appliance mode solves this issue by making sure that the return traffic always goes to the same AZ as the original traffic.
If you want to learn how to completely automate deploying the firewalls, please check out my other blog post below.
Suresh Vina
Conclusion
In conclusion, if you're looking to centrally inspect all your traffic using your own security appliances, Gateway Load Balancer simplifies this task for you. If you have any questions or feedback, please don't hesitate to let me know in the comments below.
