How VM-Series Integrates with AWS Gateway Load Balancer

Nov 10, 2020
5 minutes
457 views

We’ve just announced the general availability of the VM-Series virtual firewall integration with the new AWS Gateway Load Balancer (GWLB).  And by doing so, we’re introducing security scaling while maintaining throughput performance and bypassing many of the complexities traditionally associated with inserting virtual appliances in public cloud environments. 

First, some context: Palo Alto Networks VM-Series virtual Next-Generation firewalls augment native Amazon Web Services (AWS) network security capabilities with next-generation threat protection. VM-Series virtual firewalls help prevent exploits, malware, previously unknown threats, and data exfiltration to keep your apps and data in AWS safe. 

When it comes to deploying VM-Series firewalls in AWS, customers typically leverage an AWS Transit Gateway deployment. Like most customers, you probably connect the spoke VPCs with application workloads to the AWS Transit Gateway- and then deploy the VM-Series firewalls in dedicated security VPCs and connect to the same AWS Transit Gateway.

Tradeoff Problem #1: Scale and Throughput Performance

Until now, you had two connectivity options to route your outbound and east-west traffic through the VM-Series firewalls in your transit gateway environment:

  1. You could deploy VM-Series with encrypted tunnels using AWS Transit Gateway VPN attachments (see Figure 1). 
  2. You could deploy VM-Series in active-passive HA mode using AWS Transit Gateway VPC attachments.

The first option provides scale using equal-cost multi-path routing (ECMP) and multiple VPN attachments, but each VPN attachment offers a limited throughput of 1.25 Gbps. The second option uses VPC attachments that provide up to 50 Gbps of throughput but do not scale beyond a single active VM-Series firewall (per AWS Availability Zone).

Tradeoff Problem #2: Visibility and Centralized Firewall Management

A similar tradeoff exists for inbound traffic protection. Like most customers, you likely use a “sandwich” architecture that forces all your inbound application traffic to flow through an inbound security VPC. This inbound security VPC hosts an auto-scaling firewall stack for threat prevention (see Figure1). While this architecture enables you to centrally manage firewalls and security policies, it also requires the firewalls to apply source address translation (SNAT) on the traffic to maintain flow symmetry, thereby obfuscating the source’s identity to your applications.

Figure 1. Current transit gateway deployment models with VM-series may force customers to make tradeoffs between visibility, scalability, and performance.

AWS Gateway Load Balancer Changes the Game

With the launch of GWLB, you can now simplify your VM-Series firewall insertion and realize next-generation threat prevention at scale in your AWS environment. This new AWS managed service allows you to deploy a stack of VM-Series firewalls and operate in a horizontally scalable and fault-tolerant manner.

The integration of VM-Series virtual firewalls with the GWLB alleviates the above tradeoff concerns. This new integration enables you to use native AWS networking constructs such as VPC attachments to scale your VM-Series firewalls dynamically to match your inbound, outbound, and east-west traffic demands. 

Figure 2 illustrates how using the GWLB integration with VM-Series simplifies your AWS Transit Gateway environments. You can continue to use a centralized security VPC as you did previously. But now, you can leverage the GWLB to scale and load-balance traffic across the stack of VM-Series firewalls in your centralized security VPC. You can then expose the GWLB with the stack of firewalls as a VPC endpoint service for traffic inspection and threat prevention.

Figure 2. AWS Gateway Load Balancer simplifies VM-Series virtual firewall insertion at a higher scale and throughput performance for inbound, outbound, and east-west traffic protection.

To protect the inbound traffic, create GWLB endpoints (GWLBE1 and GWLBE2 in Figure 2) in your spoke VPCs. Next, you’ll add route rules in the spoke VPC’s Internet gateway and subnet route tables to route all inbound traffic to the VPC via the endpoints and through the firewalls.  

Similarly, to protect your outbound and east-west traffic, you can create a GWLB endpoint (GWLBE3 in Figure 2) in the centralized firewall VPC then use route rules in your VPCs and transit gateways to redirect traffic to your security VPC for inspection.  

Three ways the integration pays off

The VM-Series firewall integration with GWLB offers the following benefits:

  • Simplified connectivity - Easily insert an auto-scaling VM-Series firewall stack in the outbound, east-west, and inbound traffic paths of your applications. VM-Series and the GWLB use the GENEVE encapsulation to keep your traffic packet headers and payload intact, providing complete visibility of the source’s identity to your applications - In other words, no more SNAT. 
  • Performance at scale - Scale your traffic across multiple VM-Series firewalls at higher throughput by using AWS native networking constructs and AWS Transit Gateway VPC attachments. You no longer need encrypted tunnels for east-west and outbound traffic inspection - In other words, no IPsec tunnel overhead.
  • Cost Effective - Reduce the number of firewalls needed to protect your AWS environment and consolidate your overall network security posture with centralized security management.

To begin realizing these benefits in your AWS environment today, you can start a trial of VM-Series on AWS from the AWS Marketplace. You may also find more information on how VM-Series adds an additional layer of protection to AWS environments on the Live Community AWS resource page. And don’t forget to check our Palo Alto Networks Github repository for the latest assets to help you deploy and manage VM-Series firewalls in cloud environments.


Subscribe to Network Security Blogs!

Sign up to receive must-read articles, Playbooks of the Week, new feature announcements, and more.