Transit FireNet Workflow with AWS Gateway Load Balancer (GWLB)

The Aviatrix Transit FireNet solution allows you to deploy firewall functions with AWS Gateway Load Balancer.

If you want to deploy firewall networks in an AWS Transit Gateway (TGW) environment, your starting point is AWS TGW Transit FireNet Workflow.

In this example, Transit VPC with Aviatrix Gateways will be deployed, and two Spoke Gateways (DEV and PROD) will be attached to it as shown below:

topology_trfnet_with_gwlb

Create VPCs

VPCs can be created manually on AWS or directly from Aviatrix Controller.

  1. In the Aviatrix Controller navigate to Useful Tools > Create A VPC.

  2. Add one VPC for the Transit FireNet Gateway and select Aviatrix FireNet VPC option as shown below.

  3. Create two more VPCs with no option/checkbox selected for Spoke Gateways.

    create_vpc

Deploy the Transit Aviatrix Gateway

Transit Aviatrix Gateway can be deployed using the Transit Gateway Workflow.

Prerequisites for AWS

Transit FireNet builds on the Aviatrix Transit Network where Aviatrix gateways are deployed in both the transit VPC and the spoke VPCs in AWS.

Make sure the deployment meets the following specifications:

  1. ActiveMesh 2.0 is required (enabled by default as of release 6.0). To migrate to ActiveMesh 2.0, see Migrating from Classic Aviatrix Encrypted Transit Network to Aviatrix ActiveMesh Transit Network.

  2. The minimum size of the Aviatrix Transit Gateway is c5.xlarge.

  3. Aviatrix Transit Network must be in Connected mode. Go to Transit Network > Advanced Config > Connected Transit. Click Enable.

Procedure

  1. Navigate to Multi-Cloud Transit > Setup > Transit > 1) Launch an Aviatrix Transit Gateway.

  2. Choose instance size C5x.large.

  3. Enable High Performance Encryption (HPE) Mode for higher throughputs (optional)

  4. Enable Transit VPC GW HA by navigating to Multi-Cloud Transit > Setup > 2) (Optional) Enable HA to an Aviatrix Transit Gateway.

An instance size of c5.xlarge will be required for High Performance Encryption Mode encryption for higher throughput.

Please see an example below for Transit FireNet GW:

tr_firenet_gw

Step 3: Deploy Spoke Gateways

Now that we have Aviatrix Transit Gateway, we can deploy Aviatrix Spoke Gateways in the spoke VPCs using the Aviatrix Spoke Gateway Workflow.

  1. Navigate to Multi-Cloud Transit > Setup > Spoke > 1) Launch an Aviatrix Spoke Gateway.

  2. Deploy a Spoke Gateway (GW) in each of the spoke VPCs using defaults while choose correct Account and VPC info

  3. Choose the Public Subnet.

  4. Enable Spoke Gateway HA by navigating to Transit network → Setup → #5 (Optional) Enable/Disable HA at Spoke GW

Instance size of c5.xlarge will be required for High Performance Encryption Mode encryption for higher throughput.
launch_spk_gw

Attach Spoke Gateways to Transit Network

Now that the Transit and Spoke gateways are deployed you can connect them.

  1. Navigate to Multi-Cloud Transit > Setup > Attach/Detach > 1a) Attach Spoke Gateway to Transit Network.

  2. Select one Spoke at a time and attach to the Transit Gateway.

attach_spk_trgw
The Transit Gateway is attached to Spoke Gateways, but by default, the Transit Gateway will not route traffic between Spoke Gateways.

Enable Connected Transit

By default, spoke VPCs are in isolated mode where the Transit will not route traffic between them. To allow the Spoke VPCs to communicate with each other, you need to enable Connected Transit.

  1. Navigate to Multi-Cloud Transit > Advanced Config, select the right Transit Gateway and toggle Connected Transit to Enabled.

connected_transit

Configure Transit Firewall Network

Now that Transit and Spoke Gateways have now been deployed, enable the FireNet function and create the traffic inspection policy.

  1. Navigate to Firewall Network > Setup > Transit FireNet > 3a) Enable Transit FireNet on Aviatrix Transit Gateway.

  2. Select the Aviatrix Transit Gateway, check the Use AWS GWLB checkbox and click Enable.

en_tr_firenet_gwlb

  1. Navigate to Firewall Network > Policy.

  2. Select the Firenet Gateway Name.

  3. Add Spokes to the Inspected box for traffic inspection.

By default, FireNet inspects ingress (INET to VPC) and east-west traffic (VPC to VPC) only.
tr_firenet_policy_gwlb

Subscribe Firewall Vendor in AWS Marketplace

At this point, FireNet functionality on Transit Gateway is enabled and FireNet policy is created for spokes. It is time to subscribe the firewall vendor and deploy the firewall.

  1. In your AWS Console, navigate to the AWS Marketplace and subscribe to the Firewall Vendor Product.

  2. Follow the link to subscribe to Check Point, Palo Alto or Fortinet in AWS Marketplace.

    Please subscribe to the firewall but do not launch the firewall.

Launch and Associate Firewall Instance

This approach is recommended if this is the first Firewall instance to be attached to the gateway.

This step launches a Firewall instance and associates it with one of the FireNet gateways.

The Firewall instance and the associated Aviatrix FireNet gateway above must be in the same AZ, and, we recommend that the Management interface subnet and Egress (untrust dataplane) interface subnet should not be in the same subnet.

  1. In the Aviatrix Controller navigate to Firewall Network > Setup > Firewall and provide all the required input as shown in the table.

  2. Click "Launch".

The vendor’s firewall may take some time after launch to be available.
Setting Value

VPC ID

The Security VPC created in Step 1.

Gateway Name

The primary FireNet gateway.

Firewall Instance Name

The name that will be displayed on AWS Console.

Firewall Image

The AWS AMI that you have subscribed in Step 2.

Firewall Image Version

Firewall instance current supported software versions.

Firewall Instance Size

Firewall instance type.

Management Interface Subnet.

Select the subnet whose name contains "gateway and firewall management"

Egress Interface Subnet

Select the subnet whose name contains "FW-ingress-egress".

Username

Applicable to Azure deployment only. "admin" as a username is not accepted.

Password

Applicable to Azure deployment only.

Key Pair Name (Optional)

The .pem file name for SSH access to the firewall instance.

Attach (Optional)

By selecting this option, the firewall instance is inserted in the data path to receive packet. If this is the second firewall instance for the same gateway and you have an operational FireNet deployment, you should not select this option as the firewall is not configured yet. You can attach the firewall instance later at Firewall Network → Advanced page.

Advanced (Optional)

Click this selection to allow Palo Alto firewall bootstrap files to be specified.

IAM Role

In advanced mode, create an IAM Role on the AWS account that launched the FireNet gateway. Create a policy to attach to the role. The policy is to allow access to "Bootstrap Bucket".

Bootstrap Bucket Name

In advanced mode, specify a bootstrap bucket name where the initial configuration and policy file is stored.

Check Point Specifications

The Check Point Security Gateway does not currently support AWS GWLB.

Palo Alto VM-Series Specifications

The Palo Alto VM-series instance has three interfaces as described below.

Palo Alto VM instance interfaces Description Inbound Security Group Rule

eth0 (on subnet -Public-FW-ingress-egress-AZ-a)

Egress or Untrusted interface

Allow ALL

eth1 (on subnet -Public-gateway-and-firewall-mgmt-AZ-a)

Management interface

Allow SSH, HTTPS, ICMP, TCP 3978

eth2 (on subnet -gwlb-pool)

LAN or Trusted interface

Allow ALL (Do not change)

Note that firewall instance eth2 is on the same subnet as AWS GWLB interface.

For Panorama managed firewalls, you need to prepare Panorama first and then launch a firewall. When a VM-Series instance is launched and connected with Panorama, you need to apply a one time "commit and push" from the Panorama console to sync the firewall instance and Panorama.

If VM-Series are individually managed and integrated with the Controller, you can still use Bootstrap to save initial configuration time. Export the first firewall’s configuration to bootstrap.xml, create an IAM role and Bootstrap bucket structure as indicated above, then launch additional firewalls with IAM role and the S3 bucket name to save the time of the firewall manual initial configuration.

FortiGate Specifications

The FortiGate firewall supports AWS GWLB in their latest 6.4 release. Refer to the FortiOS 6.4 AWS Cookbook, pages 175 through 189. This section covers both North-South and East-West scenarios.

Associate an Existing Firewall Instance

This step is the alternative step to Launch and Associate Firewall Instance. If you already launched the firewall (Check Point, Palo Alto Network or Fortinet) instance from the AWS Console, you can still associate it with the FireNet gateway.

In the Aviatrix Controller navigate to Firewall Network > Setup > Firewall > 2b and associate a firewall with the right FireNet Gateway.

Example Setup for "Allow All" Policy

After a firewall instance is launched, wait for 5 to 15 minutes for it to come up. Time varies for each firewall vendor. In addition, please follow example configuration guides as below to build a simple policy on the firewall instance for a test validation that traffic is indeed being routed to firewall instance.

Palo Alto Network (PAN)

For basic policy configuration for AWS, refer to this document: Palo Alto VM-Series.

For Egress Inspection go to Enable Egress Through Firewall.

egress_gwlb

FortiGate (Fortinet)

The FortiGate firewall supports AWS GWLB in their latest 6.4 release. Refer to the FortiOS 6.4 AWS Cookbook, pages 175 through 189. This section covers both North-South and East-West scenarios.

Check Point

The Check Point Security Gateway does not currently support AWS GWLB.

Verification

There are multiple ways to verify if Transit FireNet is configured properly:

  1. Aviatrix Flightpath - Control-plane Test

  2. Ping/Traceroute Test between Spoke VPCs (East-West) - Data-plane Test

Flight Path Test for FireNet Control-Plane Verification:

Flight Path is a very powerful troubleshooting Aviatrix tool which allows users to validate the control-plane and gives visibility of end to end packet flow.

  1. Navigate to Troubleshoot→ Flight Path

  2. Provide the Source and Destination Region and VPC information

  3. Select ICMP and Private subnet, and Run the test

EC2 VM instance will be required in AWS, and ICMP should be allowed in security group.

Ping/Traceroute Test for FireNet Data-Plane Verification

Once the control-plane is established and no problems are found in security and routing polices, data-plane validation needs to be verified to make sure traffic is flowing and not blocked.

There are multiple ways to check the data-plane:

  1. SSH to Spoke EC2 instance (e.g. DEV1-VM) and ping the other Spoke EC2 to instance (e.g PROD1-VM) to make sure there is no traffic loss in the path.

  2. Ping/traceroute capture can also be performed from Aviatrix Controller. Go to Troubleshoot > Diagnostics and perform the test.

Transit FireNet with AWS GWLB Packet Walk

gwlb_impementation

Step 1: Spoke Gateway Connections and Routing Table

spk_list_1
spk_list_2

Step 2: Transit Gateway Connections and Routing Table

transit_list_1
transit_list_2
transit_list_3

Step 3: Transit to Endpoint Routing (dmz_firewall Route Table)

aws_cons_1
aws_cons_2
aws_cons_3

Step 4: AWS Gateway Load Balancer Endpoint to Gateway Load Balancer

aws_cons_4
aws_cons_5
aws_cons_6
aws_cons_7

Step 5: Load Balancer to Firewall (Palo Alto Networks)

aws_cons_8
aws_cons_9
aws_cons_10
aws_cons_11
aws_cons_12

Step 6: Load Balancer and Firewall (Palo Alto Networks) Routing image::aws-cons-13.png[aws_cons_13]

aws_cons_14

Step 7: Egress Traffic Endpoint Point to NAT GW to Internet

nat_gw_1
nat_gw_2