Transit FireNet FAQ
What is the Aviatrix Transit FireNet for AWS & Azure?
Aviatrix Transit FireNet allows you to deploy firewalls functions for the Aviatrix Encrypted Transit architecture. With Transit FireNet feature, the FireNet function is integrated into the Aviatrix Transit Gateway.
If you are looking for firewall functions deployment in AWS Transit Gateway environment, your starting point is here.
The use case is to deploy firewalls in the encrypted transit architecture for both AWS and Azure, as shown below.
When deployed in Azure, Transit FireNet also works when using Native Azure VNet Spokes, as shown below.
When deployed in Azure, only two firewall instances are supported.
Can multiple firewalls be supported in Transit FireNet?
Yes. Multiple firewall instances can be attached to each Transit Gateway. The Transit Gateway load balances and forwards packets to the firewalls.
How does Transit FireNet work?
Transit FireNet works the same way as the Firewall Network where traffic in and out of the specified Spoke is forwarded to the firewall instances for inspection or policy application.
What is the minimum gateway instance size for Transit FireNet deployment?
The minimum gateway instance size is C5.xlarge. This is because the FireNet gateway requires 4 network interfaces:
eth0 is a management interface
eth1 is not used
eth2 is the interface to the firewall instances
eth3 is the interface to the HA FireNet Gateway
What is the Transit FireNet performance?
With a pair of c5n.18xlarge Aviatrix Transit Gateway, Transit FireNet achieves 70Gbps throughput with iperf3 benchmark, as shown in the diagram below.
Note if a single c5n.18xlarge Aviatrix Transit Gateway is deployed, the throughput is about 40Gbps. This is because Aviatrix Encrypted Transit solution runs with ActiveMesh where both Transit Gateways do the packet forwarding.
Which option should I choose for the Create a VPC tool?
When using the Useful Tool to create the transit VPC/VNet for Transit FireNet deployment, select the Aviatrix FireNet VPC option to create 4 public subnets.
How do I configure FireNet?
Follow the FireNet workflow to deploy firewall in the cloud.
For a complete end-to-end example, refer to The Example Step by Step Guide for Transit FireNet in AWS.
How do I enable egress inspection on Transit FireNet?
By default, FireNet inspects traffic between North South (on-prem and VPC/VNet) and East West (VPC/VNet to VPC/VNet). To enable Egress traffic (Internet bound) inspection:
Go to Firewall Network > Advanced. Click the skewer. Scroll down to Egress through Firewall and click Enable.
When Egress through Firewall is enabled, it applies to all Spoke VPC/VNets. You do not need to configure individual VPC/VNet inspection policy.
Is Ingress Inspection supported on Transit FireNet?
Yes. You need to enable source NAT on the LAN Interface of the VM-Series.
How to exclude specific CIDRs from being inspected by the firewall?
By default, FireNet inspects all East-West (VPC/VNet to VPC/VNet) traffic but you may have an instance in the VPC/VNet which you do not want to be inspected. For example, the Aviatrix Controller deployed in the Shared Service VPC/VNet to be excluded from inspection while Shared Service VPC/VNet traffic is inspected. This improves the Controller reachability by not subjecting the Controller access to unintentional firewall policy errors.
Go to Firewall Network > Advanced and put the CIDRs in the field “Network List Excluded From East-West Inspection” to exclude from being inspected by the firewall.
Maximum 20 CIDRs coma-separated are supported.
CIDRs are excluded from East-West inspections only.
In Transit FireNet, if Egress inspection is enabled, all the Egress traffic will get inspected by the firewall even for the CIDRs excluded for East-West inspection.
Can I deploy an Aviatrix Egress Control FQDN Gateway on Transit FireNet?
Yes. Deploy Aviatrix FQDN Gateway as shown in the diagram below.
The instructions are described as the following.
What is the performance of Aviatrix Egress FQDN gateway on Transit FireNet?
Preliminary test results are as follows.
# of FQDN gateways
Is there an example guide to setup Palo Alto VM-Series policies?
Yes. Follow Example Config for Palo Alto VM-Series to setup an “ALLOW ALL” policy for test validation.
How do I test FireNet connectivity without deploying firewall instance?
You can test connectivity without deploying any firewall instances. When the FireNet Gateway has no firewall instance attached to it for the data path, the FireNet Gateway loops the received packet and forwards it to its destination.
Can VM-Series be launched with Bootstrap integration?
Yes. When you launch a VM-Series from the Aviatrix Controller, you can select the option to launch the VM-Series instance with bootstrap information.
Can Firewall Network work with Panorama?
Yes. Follow the instructions for Panorama integration.
How does the Controller check Firewall instance health?
When vendor integration is enabled, for Palo Alto Networks VM-Series, the Controller pings the individual firewall management interface every 10 seconds. If two consecutive ping fails, the firewall is declared down and is moved to “down” state. The Controller continues to ping the management interface, if consecutive pings become successful, the firewall instance is attached back to the FireNet Gateway pool.
For Check Point CloudGuard and Fortinet Fortigate, the Controller uses AWS API to check instance health.
Starting in Release 6.0 and later, Controller can also check firewall instance health on its LAN interface.
What is the firewall instance state Inaccessible mean?
The Controller periodically issues Palo Alto API calls to find out if API can be issued successfully. This is used for route updating purposes, as firewall route updates requires API to work. If Palo Alto API fails for two consecutive times, the Controller declares the firewall is in Inaccessible state, but the firewall should still be attached and be forwarded traffic as long as its health check pass.
How does Transit FireNet load balance traffic between different firewalls?
In AWS, Transit FireNet Load Balance the traffic across different firewall using five-tuple hash.
The tuple is composed of the:
Source IP Source port Destination IP Destination port Protocol type
The algorithm provides stickiness only within a transport session. Packets that are in the same session are directed to the same firewall. When the client starts a new session from the same source IP, the source port changes and causes the traffic to go to a different firewall.
Aviatrix Transit FireNet supports different hashing algorithms available in Azure cloud to load balance the traffic across different firewalls which includes Hash-based distribution mode (five-tuple hash) and Source IP affinity mode (three-tuple or two-tuple hash).
By default, Transit FireNet use 5-tuple hashing algorithm but that can be changed using Azure’s portal.
Log in to Microsoft Azure’s Portal and Go to Load balancer under Azure services.
Click the Transit FireNet where Load balancing algorithm needs to be changed.
Go to Load Balancing rules under Settings and click LBRule.
- Select hashing algorithm under Session persistence.
None > Default five-tuple (source IP, source port, destination IP, destination port and protocol type) hashing algorithm.
Client IP > This mode uses a two-tuple (source IP and destination IP).
Client IP and protocol > three-tuple uses source IP, destination IP, and protocol type.
How do I migrate from Aviatrix Transit FireNet to Transit FireNet with AWS GWLB?
Starting from Release 6.3, Multi-Cloud Transit FireNet added support for AWS Gateway Load Balancer (GWLB). The key advantage of this integration is to allow firewalls to be scaled up and down without affecting established sessions (except sessions associated with the failed firewalls).
To migrate from Transit FireNet to Transit FireNet with AWS GWLB and vice versa. Follow the steps below:
Save the firewall configuration.
Disassociate firewall instance . Go to Aviatrix Controller > Firewall Network > Setup > Step 10.
Delete firewall instances > Go to Aviatrix Controller > Firewall Network > Setup > Step 7a.
Disable Transit FireNet function > Go to Aviatrix Controller > Multi-Cloud Transit > Transit FireNet > Step 5a to disable Transit FireNet Function for Aviatrix Transit Gateway.
Enable Transit FireNet function > Go to Aviatrix Controller > Multi-Cloud Transit > Transit FireNet > Step 1a to enable Transit FireNet Function on Aviatrix Transit Gateway. Mark the Use AWS GWLB if migrating from Transit FireNet to Transit FireNet with AWS GWLB.
Launch & associate Firewall > Go to Aviatrix Controller > Firewall Network > Step 7a.
Restore firewall configuration.