VM-Series Deployment Guide
    : VM-Series Integration with an AWS Gateway Load Balancer
    Focus
    Download PDF
    Focus
    1. Home
    2. VM-Series
    3. VM-Series Deployment Guide
    4. Set Up the VM-Series Firewall on AWS
    5. VM-Series Integration with an AWS Gateway Load Balancer
    Download PDF

    VM-Series Deployment Guide

    VM-Series Integration with an AWS Gateway Load Balancer

    Table of Contents

    VM-Series Integration with an AWS Gateway Load Balancer

    Learn more about the VM-Series firewall integration with the AWS Gateway Load Balancer.
    The AWS Gateway Load Balancer (GWLB) is an AWS managed service that allows you to deploy a stack of VM-Series firewalls and operate in a horizontally scalable and fault-tolerant manner. You can then expose the AWS GWLB with the stack of firewalls as a VPC endpoint service for traffic inspection and threat prevention. By creating Gateway Load Balancer endpoints (GWLBE) for the VPC endpoint service, you can easily insert an auto-scaling VM-Series firewall stack in the outbound, east-west, and inbound traffic paths of your applications. VM-Series firewalls 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.
    When integrated with a GWLB, a VM-Series firewall receiving GENEVE encapsulated-traffic cannot terminate IPsec tunnel traffic.
    The VM-Series firewall supports decryption when deployed behind a GWLB for forward and inbound use cases, including TLS1.2 and TLS1.3 utilizing DHE/ECDHE ciphers.
    The image below describes how the integration of GWLB with VM-Series simplifies your AWS transit gateway(TGW) environments. You attach a centralized security VPC to your transit gateway. The centralized security VPC includes a GWLB to scale and load-balance traffic across the stack of VM-Series firewalls.
    Deploying the VM-Series firewall behind a GWLB requires you to configure the AWS transit gateway.
    To ensure that the VM-Series firewall can inspect traffic that is routed between VPC attachments, you must enable appliance mode on the transit gateway VPC attachment for the security VPC containing the VM-Series firewall. You can enable appliance mode using the command: 
    modify-transit-gateway-vpc-attachment --transit-gateway-attachment-id <value> --options ApplianceModeSupport=enable
    For more instructions, see enabling appliance mode.
    This ensures that bidirectional traffic is routed symmetrically—both request and response traffic are directed to the same Gateway Endpoint in the firewall VPC and the GWLB will maintain persistence to the same VM-Series firewall for inspection before continuing to the correct destination.
    When deployed with a GWLB, you can use the VM-Series firewall to protect:
    • Inbound traffic—traffic originating outside the VPC and destined to resources within your application VPC, such as web servers. VM-Series firewalls prevent malware and vulnerabilities from entering the network in traffic allowed by AWS security groups.
    • Outbound traffic—traffic originating within the application VPCs and destined to external resources on the Internet. The VM-Series firewalls protect outbound traffic flows by ensuring that workloads in application VPCs connect to permitted services (such as Windows Update) and allowed URL categories and preventing data exfiltration of sensitive information. Additionally, VM-Series security profiles prevent malware and vulnerabilities from entering the network in the return traffic.
    • East-West traffic—in a transit gateway environment, East-West traffic refers to Inter-VPC traffic, such as the traffic between source and destination workloads in two different application VPCs. The VM-Series firewalls protect east-west traffic flows against malware propagation.
    To protect the inbound traffic to your application VPCs:
    1. Create GWLBE endpoints(GWLBE1 and GWLBE2 in the figure above) having separate subnets associated in your spoke VPCs. Ensure that you have separate subnets for GWLB Endpoints, ALB, and Application and Transit Gateway attachment within the application VPC.
    2. Add route tables in the application VPC (in addition to the VPC local route) as follows:
      1. Route table with IGW edge association - Add route destined to ALB with target as GWLBE.
      2. Route table with ALB subnet association - Add route destined to 0.0.0.0/0 with target as GWLBE.
      3. Route table with GWLBE subnet association - Add route destined to 0.0.0.0/0 with target as IGW.
    With these routes in place, the inbound traffic arriving at VPC IGW is routed towards GWLBE. The GWLBE forwards the traffic to GWLB which in turn sends the traffic to the VM-Series Firewall in the Security VPC for inspection. The firewall sends the request traffic back to the application VPC GWLBE, which then forwards the traffic to the application through ALB. Response traffic to this request is sent by ALB towards the application GWLBE which then sends the traffic to GWLB. The GWLB in turn sends the traffic to the VM-Series firewall. After inspecting the response traffic, the firewall sends the response traffic back to the application GWLBE which in turn sends the traffic to IGW.
    To protect the outbound traffic of the application VPCs:
    1. Create a GWLBE(GWLBE3 in the figure above) in the centralized firewall VPC. Ensure that you have separate subnets for GWLB Endpoint, Transit Gateway attachment, NAT Gateway within the Security VPC.
    2. Create a NAT Gateway in the Security VPC.
    3. Add route tables as follows:
      1. Route table with Application subnet association - Add route destined to 0.0.0.0/0 with target as TGW. This is in addition to the VPC local route.
      2. Route tables in Security VPC:
        • Route table with TGW attachment subnet association - In addition to VPC local route, add route destined to 0.0.0.0/0 with target as GWLBE3.
        • Route table with GWLBE subnet association - In addition to VPC local route, add route destined to 0.0.0.0/0 with target as NAT Gateway. Add route destined to Application VPC CIDRs with target as TGW.
        • Route table with NAT Gateway Subnet association - In addition to VPC local route, add route destined to 0.0.0.0/0 with target as IGW. Add route destined to Application VPC CIDRs with target as GWLBE3.
      3. Add Transit Gateway Route tables as follows:
        • Route table with App1-1 VPC TGW-Attachment association - Add route destined to 0.0.0.0/0 with attachment ID as Security VPC TGW attachment.
        • Route table with App2-2 VPC TGW-Attachment association - Add route destined to 0.0.0.0/0 with attachment ID as Security VPC TGW attachment.
        • Route table with Security VPC TGW-Attachment association - (a) Add route destined to App-1 VPC CIDR with attachment ID as Application-1 VPC TGW attachment. (b) Add route destined to App-2 VPC CIDR with attachment ID as Application-2 VPC TGW attachment.
      With this configuration in place, outbound traffic initiated from Application(App1) is sent to TGW and TGW forwards that to the Security VPC subnet. The traffic is then routed to Security GWLBE(GWLBE3) which sends the traffic to VM-Series firewall for inspection through GWLB. The VM-Series firewall sends the traffic back to GWLBE3 after inspection and GWLBE3 forwards the traffic to NAT Gateway which sends the traffic through IGW. Similarly, the response traffic passes through the NAT Gateway to GWLBE3, VM-Series firewall, and TGW after which it is routed back to the application.
      The East-West traffic is also managed with the routes and configuration described in the steps above. When the traffic is sent from App1 to App2, the traffic passes through TGW which routes the traffic to GWLBE3. The GWLBE3 forwards the traffic to the VM-Series firewall through GWLB. The VM-Series firewall sends the packet back to GWLBE3 after inspection. GWLBE3 then forwards the packet to App2 through TGW. The response traffic from App-2 to App-1 will take the reverse path.
      It is recommended to have all subnets in the same AZ to avoid cross-zone traffic charges.

    © 2024 Palo Alto Networks, Inc. All rights reserved.