使用 Gateway Load Balancer 和 Palo Alto 防火墙实现集中的网络流量深度检测丨Use Gateway Load Balancer and Palo Alto Firewall for centralized deep inspection of network traffic

Chapter 1 Overview

1.1 Background

Amazon Web Services China announced full integration support between Amazon Gateway Load Balancer (GWLB) and Palo Alto Networks’ VM-Series virtual firewall. This latest service will greatly facilitate users to deploy, expand, and manage third-party virtual devices and services in Amazon Web Services, making security gateways and virtual firewall products have greater security expansion and performance enhancement capabilities.

1.2

When deploying VM-Series firewalls in Amazon, customers often use Amazon Transit Gateway for deployment. Like most customers, you might connect a branch VPC with application workloads to Amazon Transit Gateway, then deploy a VM series firewall in a dedicated security VPC and connect to the same Amazon Transit Gateway.

Before GWLB was introduced, we usually only used NLB or ALB to mount two firewalls to control inbound traffic load balancing and achieve high firewall availability. However, when it comes to controlling outbound traffic, it is not possible to achieve high firewall availability. Users will have to compromise between convenience, scalability, performance, and security consistency.

Below are the architectural challenges should Amazon Gateway Load Balancer (GWLB) is not used:

Challenge #1 — Compromise between deployment scale and throughput performance

Through the Amazon Transit Gateway environment, you have two connectivity options to secure outbound and east-west traffic for VM-Series firewalls:

You can deploy a VM series with an encrypted tunnel using the Amazon Transit Gateway VPN attachment (see Figure 1).

You can use the Amazon Transit Gateway VPC attachment to deploy the VM series in an active-passive HA mode.

— The first option provides the scale to use Equal-Cost Multi-Path Routing (ECMP) and multiple VPN connections, but each VPN connection provides limited throughput at 1.25 Gbps.

— The second option uses a VPC attachment and provides up to 50 Gbps of throughput, but doesn’t scale to every single active VM series firewall (each Availability Zone).

Figure 1: The current transit gateway deployment model using the VM family may force customers to make trade-offs between visibility, scalability, and performance.

Challenge #2 — The challenge of centralized management based on visibility and firewall

There is a similar trade-off for inbound traffic protection. Like most customers, you might use a “sandwich” architecture that forces all inbound application traffic to flow through an inbound secure VPC. This inbound security VPC hosts an automatically scaled firewall stack for threat prevention (see Figure 1). While this architecture enables you to centrally manage firewalls and security policies, it also requires the firewall to apply source address translation (SNAT) to traffic to maintain flow symmetry, thus obscuring the source identity of your application.

The integration of VM series virtual firewalls with GWLB mitigates these trade-offs.

This new integration, shown in Figure 2, enables you to use native Amazon networking architectures (such as VPC attachments) to dynamically expand your VM series firewall to match your inbound, outbound, and east-west traffic requirements.

Figure 2. The Amazon Gateway Load Balancer simplifies the insertion of VM series virtual firewalls with higher scale and throughput performance to protect inbound, outbound, and east-west traffic.

1.3

The introduction of GWLB enables firewalls to simultaneously detect inbound and outbound traffic when high availability is achieved. GWLB uses the Geneve protocol (UDP 6081) to establish communication with the firewall, forward the received traffic to a set of back-end firewalls, and implement management functions such as health checks, load balancing, and sticky links. Deploying VM-Series firewalls using GWLB’s architecture will have the following advantages:

Simplified connectivity: Easily plug in an automatically expanded VM series firewall stack into the application’s outbound, east-west, and inbound traffic paths. The VM series and GWLB use GENEVE encapsulation to keep your traffic packet headers and payload intact, providing your application with full visibility of the source identity — in other words, no more SNAT.
Performance at scale: Scale your traffic across multiple VM series firewalls with higher throughput by using the Amazon native network fabric and the Amazon Transit Gateway VPC attachment. You no longer need an encrypted tunnel for east-west and outbound traffic inspection—in other words, no IPsec tunneling overhead.
Cost-effectiveness: Reduce the number of firewalls needed to protect the Amazon environment and consolidate the overall cybersecurity landscape through centralized security management.

Chapter 2. Deployment Planning

2.1 Plan the topology

The deployment topology diagram is shown below:

2.2 Deployment instructions

GWLB components:

Customer VPC: The VPC where the application is located
GWLB Endpoint: A virtual network card placed in the Customer VPC as the next hop for the route. Cross-AZ redundancy requires a GWLB endpoint in each AZ
Ingress Router: Internet entrance route table bound to IGW
GWLB: A 4-layer load balancing service placed in the Security VPC. Each availability zone will create a network interface and obtain an address to establish a GENEVE tunnel with the PA firewall
GWLB Private Link: There is no need for a VPC peer between the Customer VPC and the Security VPC; the GWLB Endpoint connects to GWLB load balancing through GWLB private link

Inbound traffic forwarding process (red path):

Ingress traffic enters the IGW ingress route table
The ingress route table points the next hop of the business server gateway route to the GWLB endpoint virtual network card
GWLB endpoint forwards data to GWLB, GWLB loads traffic to PA, and PA sends back processed traffic to GWLB
GWLB sends back the data to the GWLB endpoint, and the GWLB endpoint forwards the data to the application instance

Outbound traffic forwarding process (blue path):

In the application instance route table, next hop is to the GWLB endpoint.
GWLB endpoint forwards data to GWLB, GWLB loads traffic to PA, PA sends back processed traffic to GWLB, and GWLB sends back data to GWLB endpoint.
GWLB endpoint forwards to IGW
IGW forwards outbound traffic to the Internet

Chapter 3. Deployment steps

3.1 VPC configuration

3.1.1 Create two VPCs

Name /Network Segment / Remarks
pa-test-APP 10.10.0.0/16 VPC where the application is located
pa-test-SEC 10.20.0.0/16 VPC where PA firewall is located

3.1.2 Creating a Subnet

APP-VPC 2 subnets

Name /Network Segment / Remarks
pa-test-APP-APP01 10.10.20.0/24 The subnet where the application is located
pa-test-APP-GWLBe01 10.10.10.0/24 The subnet where the GWLBE is located

SEC-VPC 4 subnets

Name / Network Segment / Remarks
pa-test-SEC-GWLB01
10.20.10.0/24 the subnet where
GWLB（AZ-1a）is located, PA01-untrust interface

pa-test-SEC-GWLB02 10.20.30.0/24 the subnet where GWLB（AZ-1b) is located, PA02-untrust interface

pa-test-SEC-MGT01 10.20.20.0/24 PA01-MGT interface
pa-test-SEC-MGT02 10.20.40.0/24 PA02-MGT interface

3.1.3 Creating a route table

App-VPC has 3 route tables:

The IGW ingress route table is associated with the IGW. There is no need to associate other subnets to control ingress routes.

GWLBE route table is associated with the GWLBE subnet

App route table is associated with the Application subnet

3.2 Create and configure a PA firewall

3.2.1 Create a PA firewall instance

When creating the instance, select Amazon Marketplace, search for Palo Alto, and select the VM Series image (10.2.2. h2 version).

Select the c5.xlarge version:

Select the correct VPC and subnet:

Here, you need to select the untrust subnet as the PA’s default first network card.

Set an IP address for the interface, add a network interface, select the MGT subnet, and set the IP address;

PA’s first network interface and IP:

PA’s secondary network interface and IP in MGT subnet:

In the advanced options user data part, enter mgmt-interface-swap=enable to exchange the mapping of the two ports.

Enter plugin-op-commands=aws-gwlb-inspect: enable to allow PA and GWLB to communicate:

When adding storage, tags, and security groups, leave the default options and continue to next step

Select a key pair and launch:

Turn off PA source/destination address checking.

Select Instance – Actions – Network – Change Source/Destination Address Check:

You need to allocate an EIP to the PA management port to facilitate management through the public network.

Create a new route table in the SEC VPC, associate the two PA management port subnets, and configure the default route to point to the IGW of the SEC VPC, so that the PA management port can be accessed through EIP.

3.2.2 Firewall initialization

Use the chmod command to grant 400 permissions to the previously obtained key, then log into the firewall via SSH. Use the “set mgt-config users admin password” command to modify the initial password, and commit to confirm the changes.

3.2.3 Install the AWS GWLB plugin on the VM-Series firewall.

Install the plugin on the VM firewall command line using “request plugins vm_series aws gwlb inspect enable yes”. Verify the installation by running “show plugins vm_series aws gwlb”. If “GWLB enabled” shows as “True”, the plugin has been successfully installed and enabled.

3.2.4 License activation

Access the PA firewall web console through https://52.80.87.167, Enter License. After entering and successfully verifying, the system will automatically reboot.

3.2.5 Log in to the PA web configuration interface for device configuration

Navigate to NETWORK-Interfaces-Ethernet, edit ethernet1/1 to Layer3, and edit Virtual Router to default, Security Zone to Untrust.Configure the first interface to DHCP mode:

Enable interface ping, HTTP, and HTTPS functions

GWLB uses TCP protocol/port 80 to perform a health check on the PA.

Create a test policy named “Anypermit”, set the Source and Destination to “any”, and set the Action to “Allow”.

3.3 Create an application instance

Start a Windows instance in subnet pa-test-APP-APP01.

Allocate an EIP to this Windows instance.

Through EIP, you can directly connect to this Windows instance remotely and start the IIS service.

If you access the EIP through the public network, you can access the server’s web page

3.4 Create a GWLB and load target groups

Create a Gateway Load Balancer

Select the SEC VPC; since the PA uses a dual availability zone deployment, you need to select two availability zones. Each availability zone uses a separate address to establish a GENEVE tunnel with the PA in the same availability zone.

Create the target group and name it GWLB-target-group, select the instance as the target.

select the GENEVE protocol, select VPC-10.20.0.0 for VPC, select the default TCP type for Health check.

Configure the route, and enable HTTP management services on the detection protocol TCP, port 80, PA interface and click Next.

Continue the GWLB creation, click the refresh button and select the target group of pa-test-gwlb as the IP listener routing target and click create load balancer.

Edit load balancer attributes and enable cross-region load balancing in the Availability Zone routing configuration.

Check the target group and wait for the health check to pass.

If the Registered Targets Health Status appears as ‘unhealthy’, you can try changing the Health Check Protocol to HTTPS, the Health Check Path to /php/login.php, and set the Health Check Port to 443. Using TCP or HTTPS as the way of Health check depends on the PA versions and configuration.

3.5 Creating a GWLB endpoint service

VPC > Virtual Private Cloud > Endpoint Service

Associate GWLB, remove the Require acceptance for endpoint option

Copy the GWLB Endpoint service name

VPC > Virtual Private Cloud > Create a virtual network card for the GWLB endpoint

Search for the service by name, click Verify that the service is available, and select the APP VPC and corresponding subnet.

Just wait until the GWLB endpoint status becomes available

3.6 Modifying the Route Table

In the Ingress route table, add a route to the server subnet (10.10.20.0/24) and point to the GWLB endpoint

In the GWLBe subnet route table, add a route to the 0.0.0.0/0 subnet and point to the IGW of the VPC

In the App subnet Route Table, add a route to the 0.0.0.0/0 subnet and point to the GWLB endpoint

CHAPTER 4

The test was divided into two parts: business access and internal Internet access, corresponding to inbound traffic and outbound traffic, respectively. According to the the test results, the corresponding access logs can be seen on the two PA firewalls at the same time. This indicates that GWLB has successfully forwarded traffic to the PA and achieved high availability. At the same time, PA can control incoming traffic, identify applications, and detect threats.

4.1 Business Access

Test method:

140.179.163.188 is the public network address of the server, and 210.13.100.27 is the client address.

Access the server’s public network address through the client browser to see if the IIS page can be opened;
Access the server’s public network address through remote control software to check whether the server can be controlled/managed remotely;
Check whether the relevant logs are recorded on both PAs.

Screenshot of the test:

IIS page opened successfully

Successful remote control of the server

PA records to the access server IIS service log, port 80

PA records to remote control server logs, port 3389

Test conclusion:

Both PA firewalls recorded server business access logs, and the test was successful. The high availability function works fine.

4.2 Internal Internet access