Featured image of post What is an AWS Gateway Load Balancer anyway? (Part 1)

What is an AWS Gateway Load Balancer anyway? (Part 1)

Network Appliances and Firewalls in the Cloud have always been a problem for organisations, the AWS Gateway Load Balancer opens up a number of additional doors to enable successful migrations to the cloud.

So, you have a need to put a firewall appliance in the cloud, you have security pushing you hard to ensure that it has to be this appliance, and it only comes as an AMI to run on EC2. What if there is a very specific security need? Maybe compliance reasons, or even as simple as just ensuring that those that look after the network are able to manage this new network in the cloud. AWS has a solution for you! The AWS Gateway Load Balancer.

Luck would have it, I was working with a customer that had this very specific requirement as part of their migration into AWS. They had to continue to keep the level of governance on the traffic moving in and out of AWS, while also reducing the amount of time the customer needed to re-train their employees.

As much as it would be simple to say, let’s spin a GWLB up and start using it, there are some caveats to the install, but hopefully this quick guide will help you through this.

AWS released the GWLB as part of an additional service that can enable scalability to instances that once were considered the “pets” of the cloud world. Now it would be possible to use appliances on EC2, that supported the GENEVE protocol, in an auto-scaling, multi-availability zone (Multi-AZ), highly available deployment, removing a lot of the overhead required to look after a number of unique appliances. This half way house between fully cloud native and physical data centre deployments opened up the door to much more secure and acceptable cloud based deployments.

To dive into this further we will need to discuss a few concepts, that while sounding new, actually isn’t that far off what you would expect from a cloud deployment using load balancers.

What is the GENEVE protocol?

In simple terms, it is an encapsulation protocol. I would highly recommend for more information, reading Benjamin Schmaus blog post on What is GENEVE? on the RedHat site.

We see encapsulation in every day life, as well in the networking world, we just sometimes miss the comparisons. An example would be a letter sent by good ole “snail mail”, you usually start with the message inside the envelope, then you put a name, address, postal code, and sometimes the country (or the planet!). Now looking at the order in reverse we can start to see how you have encapsulated your message to then have this be received by the correct person.

  • Country - Gets you to the right local area in planet earth
  • Postal Code - The main part that is needed, in most cases this gets you down to the street level or building level
  • Address - These days, not actually needed with the post code, but within the address, you might have a building number or name
  • Person’s Name - Now that it is in the right building, the right person can open the message

There we have “encapsulation” broken down, you can then apply this to the GENEVE protocol.

  • The payload from the client or service is generated
  • Additional headers including the ethernet headers for the original payload are added
  • Additional GENEVE specific headers are added including protocol type and Virtual Network Identifier (VNI)
    • Here is where a new GENEVE payload is generated
  • Further ethernet headers are added to the new payload that includes the new ethernet headers, IP, and packet types

For more technical detail see the RFC8926, Section 3

At this point the original payload can be moved around without changing the content allowing this to be shipped to the firewall appliance, where the payload can then be broken down, scanned, and the headers put back on, and sent back. Once sent back, the GENEVE specific encapsulation is removed, and the payload can continue along to its destination.

This is why the AWS Gateway Load Balancer can be so powerful when dealing with traffic that needs to be evaluated. As the original payload is encapsulated, you could have a fleet of load balanced network appliances filtering the traffic, something not possible with traditional networking. (Big caveat that networking is a large and wonderful subject, whereby you could do this, but for the sake of simplicity, a basic network typically won’t have this level of networking!)

How does this work in AWS?

Just setting up a simple Gateway Load Balancer in AWS isn’t the whole set up. Unlike Application Load Balancers working at the Layer 7: Application layer of the OSI model, which when configured correctly, points to it’s destination and serves the traffic, or the Network Load Balancer working at the Layer 4: Transport layer, the Gateway Load Balancer takes it one further level up to the Layer 3: Network layer directly. As this is higher up the OSI model, it means that traffic manipulation needs additional features added to enable the payload to reach the correct destinations.

To make this work, we need to take a look at two additional features that exist in the AWS world:

  • VPC PrivateLink (VPC Endpoints)
    • Much like other services that use VPC Private Link, this enables you to share services within AWS without giving direct network access to the service in question. Using a VPC Endpoint Service, you can connect this up to a compatible service, like a Load Balancer, and share the Endpoint to another place in AWS.
  • Edge Associated VPC Route tables
    • This additional feature is where the “magic” happens! Building route tables, you would normally attach them to subnets within the VPC to create routes and help network traffic reach the correct destination. With an Edge Associated Route, this route can be attached to the Edge of the VPC, one that a Internet Gateway will recognise and route traffic accordingly. This routing method linked to the VPC Endpoint above, means that you can tell traffic which is bound for the VPC from an external source to route itself to the VPC endpoint of the Gateway Load Balancer,

Once the payload hits the AWS Gateway Load Balancer (GWLB), the GENEVE protocol elements are added, and the encapsulated payload is sent to the network appliances. A compatible network appliance completes the work it needs to do on the payload, sends it back through to the GWLB’s VPC Endpoint, where the payload continues onto its original destination, as the stripped headers will contain the networking information required as it was prior to the encapsulation.

Traffic flow for the Gateway Load Balancer

The flow goes as follows:

  1. Traffic destined for the External IP of the Application Load Balancer hits the Internet Gateway, using the Edge Associated Route Table, in the translation between the External IP and the Internal IP, traffic is redirected to the Gateway Load Balancer’s VPC Endpoint
  2. The payload is then transported over to the VPC Endpoint Service linked to the Gateway Load Balancer
  3. From the VPC Endpoint Service, it reaches the Gateway Load Balancer
  4. The payload then reaches the Gateway Load Balancer, where the GENEVE headers are added, so that the payload knows to send the data to the Network Appliance running on EC2, and part of the GWLB target group.
  5. Once filtered or checked by the network appliance, the payload is then sent back to the Gateway Load Balancer where the packets are un-encapsulated.
  6. The payload is then pushed back to the VPC Endpoint Service
  7. The payload reaches its original deviation point, at the VPC Endpoint in the VPC where the traffic was originally destined.
  8. As the packet is no longer encapsulated, this means that the payload is then able to successfully travel to it’s intended destination, the Application Load Balancer.
  9. At this point the payload is as normal, for any load balancing, and it will reach the destination specified in the target group for the ALB, an EC2 instance in this case.

What’s next?

With the flow in mind, and the way that the payload is encapsulated through the AWS Gateway Load Balancer, that opens up a number of options that were usually closed off for organisations. To put this into practice, there are still some additional steps that you need to take.

In the next part of my blog series, I will show how to take the new service and link it together in a network design that could be used for larger organisations that require a higher level of control over their network, while still being able to use legacy on premise networks!

I am not one for hiding behind the “you will see next time”, but what I do have are links to the code samples I will be using! Means you can also get a head start!

I will also be concentrating on a Firewall Appliance created by Check Point. The reason for this, is that I have been working with a customer using this service and they have an existing AWS Marketplace profile that contains a number of appliances, including a CloudGuard Network Security for the Gateway Load Balancer appliance, which has been specifically modified to work with the GENEVE protocol.

Code examples are available here for this type of service:

Built with Hugo
Theme Stack designed by Jimmy