1

Aviatrix FireNet in AWS with GWLB and Palo Alto Firewalls

Overview

When you have the need to deploy a firewall (FW) in conjunction with Aviatrix Transit, you need to configure the transit VPC with FireNet. This allows you to insert the firewall in a simple manner and redirect traffic to the firewall for inspection between VPCs or to the Internet (egress) depending on what you are trying to inspect on your network. Both options are available from the Aviatrix Controller.

There are two ways to deploy firewalls with Aviatrix Transit in AWS:

  1. You can deploy firewalls and attach them to the transit and transit-hagw gateways directly and let the transit gateways load balance between the active firewalls or
  2. You can deploy an AWS Gateway Load Balancer (GWLB) and deploy the firewalls as part of the target group of the GWLB

The purpose of this blog is to guide you deploying Palo Alto (PA) firewalls using option 2 above (using AWS GWLB). For the purpose of this blog, we assume the reader is familiar with the Aviatrix concepts, networking, AWS native cloud constructs, and Palo Alto firewalls.

Introduction

Before you can start deploying a firewall, the FireNet feature needs to be enabled when a VPC is created from the Aviatrix Controller. The Controller creates multiple subnets within the VPC. These subnets play a specific role in the overall design, and the subnets are created in multiple availability zones for resiliency. For additional information read FireNet Workflow.

Typically, FireNet is deployed in the transit VPC, but it could also be deployed in a dedicated transit (centralized) depending on your overall design. For additional information read Transit FireNet Design Patterns. For the purpose of this blog, FireNet is enabled in the transit VPC. After the Aviatrix Transit Gateways are deployed in the transit VPC, in the Controller, navigate to Firewall Network -> Setup, scroll down to step 3a, select the appropriate transit gateway, check the box to use AWS GWLB, and enable the FireNet Function. The Controller creates additional subnets within the transit VPC to accommodate the deployment of the GWLB.

 

Once the environment is ready, you can proceed to instantiate the FW from the Controller, it will deploy the FW with multiple interfaces and will add the FW to the target group of the GWLB automatically. This process takes several minutes to complete so be patient. The diagram below represents the configuration and where the interfaces are deployed respectively.

Palo Alto Firewalls

For the Palo Alto (PA) firewall to integrate with the GWLB it needs to use the Geneve protocol per the GWLB requirements. When you deploy the Palo Alto firewall from the Aviatrix Controller, it configures the PA to integrate with the GWLB automatically. If you want to deploy the PA manually or you have existing PAs that you want to integrate with the GWLB, follow this process from Palo Alto. In summary the process states to run these two commands from the PA CLI:

mgmt-interface-swap=enable

 

  • This command swaps eth0 and eth1, you need to plan as your management interface is going to move to where eth1 is deployed. Make sure you can access the PA from this VPC. Check subnet routing table and any security groups
plugin-op-commands=aws-gwlb-inspect:enable
  • This command allows the PA to interface with the GWLB and create an overlay (using GENEVE) between the GWLB and the PA

Now that we have the infrastructure in place, and the PAs deployed, let’s check our inspection options.

1)    Traffic Inspection

Traffic inspection allows you to inspect traffic between your VPCs (East-West) by configuring the Transit FireNet Policy in the Controller, by assigning VPCs to the policy. When traffic arrives to the transit gateways it will check if the traffic meets the configured policy. If it does, then traffic is redirected to the PA for inspection. If it doesn’t, traffic is sent to its destination directly. Because the traffic between the GWLB and the PA is an overlay, all the traffic entering and leaving the PA go through same interface (eth2 – LAN). There is no need to configure any routing in the PA’s virtual router as the traffic never leaves the overlay. The diagram below depicts the traffic path for inspection (Blue Line).

2)    Egress Traffic Inspection

 

If you want traffic to be inspected when destined to the Internet (egress), you need to enable FireNet for it. In the Aviatrix Controller, navigate to Firewall Network -> select List, and from the list select the FireNet you want to enable Egress for and click Details. Then click Enable under Egress Through Firewall.

Now that egress is enabled you can verify this on the FireNet list to make sure it was enabled successfully.

With egress inspection enabled your next step is to decide how to configure the firewall. There are two options:

  1. Palo Alto with Single interface
  2. Palo Alto with Two interfaces

2.1) Palo Alto with Single Interface

This is the default configuration, basically all the traffic entering and leaving to the Internet use the single interface. Traffic destined to the Internet arrives at the PA on the LAN interface from the GWLB via the Geneve overlay. Traffic is inspected and the traffic does a U turn on the same interface and it is sent back to the GWLB which then sends the traffic to the NAT Gateway, which is deployed as part of enabling Egress for FireNet. As mentioned earlier Geneve is an overlay in the PA so even if you have a second interface (outbound, untrust, or WAN) configured on the PA, traffic will never use this interface. If you monitor the traffic on the PA, you will see traffic arrive in the LAN zone and it is destined for the LAN zone as well.

From the PA CLI you can run this command and see that Overlay routing is disabled

show plugins vm_series aws gwlb
GWLB enabled:     True
Overlay Routing:  False
-------------------------------------------------------------
VPC endpoint                    Interface
--------------------------------------------------------------

The diagram below shows the traffic path for this option (blue line)

 

2.2) Palo Alto with Two interfaces

For this configuration, traffic destined to the Internet arrives at the PA on the LAN interface from the GWLB via the Geneve overlay. Traffic is moved out of the overlay; it is inspected and if allowed then it is SNATed to the PA outside (WAN) interface and sent to the next hop which could be an Internet Gateway or a NAT gateway. Because the traffic is now out of the overlay then the PA also needs to have a route to the Internet via the WAN interface otherwise it will be black holed. You also need to create the proper NAT policy for traffic leaving the firewall. If you monitor the traffic on the PA, you will see traffic arrive in the LAN zone and it is destined for the Outside zone which is different than the previous use case.

To enable overlay routing, run the following command from the PA CLI

request plugins vm_series aws gwlb overlay-routing enable yes

To verify the routing is allowed, run this command, and see that Overlay routing is enabled.

show plugins vm_series aws gwlb
GWLB enabled:     True
Overlay Routing:  True
-------------------------------------------------------------
VPC endpoint                    Interface
--------------------------------------------------------------

The diagram below shows the traffic path for this option (blue line). From the firewall, the traffic could go to the Internet gateway (pictured) or to the NAT gateway (not pictured)

 

Conclusion

As you can see in this blog Aviatrix interacts in a simple way with Palo Alto firewalls. You need to plan, check your security policy, and decide how you will deploy your firewalls. As shown in this blog there are two ways to configure the Palo Alto firewall for egress traffic inspection to the Internet. Take this into consideration in your overall design.

Resources

AWS GWLB

VM-Series Integration with an AWS Gateway Load Balancer

Manually Integrate the VM-Series with a Gateway Load Balancer

Enable Overlay Routing for the VM-Series on AWS

Aviatrix Config for Palo Alto Network VM-Series in AWS

Reply Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
Like1 Follow
  • 1 Likes
  • 5 mths agoLast active
  • 170Views
  • 1 Following