Overview of Firewall Network (FireNet)

FireNet is a solution for integrating firewalls in the Transit Gateway (TGW) deployment for any Cloud Service Provider CSP): AWS, Azure, GCP, or OCI.

If you are looking for firewall integration solution on Azure or in Aviatrix Multicloud transit architecture, your starting point is here.

The following firewalls are supported:

The FireNet solution has been validated to work with Check Point, Fortinet FortiGate and Barracuda CloudGen Firewall.

Multiple firewall instances can be attached to each Transit Gateway. The Transit Gateway load balances and forwards packets to the firewalls.

You can have multiple Firewall Domains. However, a Network Domain cannot be connected to two Firewall Domains except the case when one is for Ingress/Egress and another is for East-West and North-South inspection.

If using Centralized FireNet (AWS only), AWS FireNet with GWLB cannot attach to Primary.

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.

Complete all FireNet workflow steps.

If you have an instance in one VPC/VNet/Domain and another instance in a different VPC/VNet/Domain, and you specify a connection policy between the Domains and for one Domain to connect to the Firewall Domain, then you should be able to ping the two instances.

For East-West (VPC/VNet to VPC/VNet) and North-South (on-prem to VPC/VNet) traffic inspection, FireNet achieves 40Gbps throughput with Jumbo frame size in AWS. Note the maximum TGW performance between two attached VPC/VNets is 50Gbps.

The minimum gateway instance size for FireNet deployment (for TGW FireNet or Transit FireNet) is C5.xlarge. This is because the FireNet gateway requires four network interfaces:

The private interfaces on FireNet Gateway are described as below.

On a firewall LAN interface, there are two interfaces: eth2 on PAN; or eth1 on FortiGate and Check Point. This interface accepts all data traffic to be inspected or that is going to the Internet (if egress is enabled). The traffic originates from an internal instance, which has a destination of another internal instance or the Internet. Therefore, it is fine to limit this SG to RFC1918 only. But if there are non-RFC1918 CIDR’s inside your network, those may not work.

On a FireNet gateway, there are four interfaces:

In AWS (not AWS TGW), you can deploy a Centralized FireNet architecture that consists of one Primary and up to ten Secondary Transit FireNet gateways. This allows you to scale to more than 125 HPE-enabled Spokes and reduce the number of overall firewall deployments.

The Primary FireNet in a Centralized FireNet architecture is the Aviatrix Transit Gateway where firewalls are attached. The Primary FireNet can also have its own Spoke gateways and Site2Cloud or external connections. If desired you can use an AWS GWLB as the Primary FireNet.

When a regular Transit FireNet gateway is attached to Primary it is converted to Secondary automatically. Both Primary and Secondary FireNets are capable of cross-region peering.

Secondary FireNet gateways send traffic to the Primary FireNet to be inspected by the firewall. A Secondary FireNet can only attach to one Primary FireNet. Secondary FireNets can bypass Primary if the traffic does not require inspection. Traffic that does not require inspection is routed to the closest next hop.

Firewall Network is the new iteration from Transit DMZ. FireNet decouples the firewall deployment from the path between on-prem and Aviatrix Transit VPC/VNet, yet provides the same traffic inspection functions and more scale out capabilities.

If the firewall instance is in the same AZ and on the same subnet with the primary gateway, packets are forwarded directly from the gateway to the firewall instance. However, if the firewall instance is in a different AZ and subnet, forwarding packets directly to the firewall instance requires that the AWS route table be programmed with target as the firewall instance. As a result, there cannot be more than one firewall instance in the different AZ, thus losing the scale out capability.

There are two native deployments: TGW VPN to connect to firewall or TGW VPC attachment to connect to firewall.

The three different deployment models are illustrated in the diagram below.

If an AWS Transit Gateway connects to a firewall by using its built in VPN function, it must run IPsec and BGP. If you run more than one firewall instance using ECMP, each firewall instance must configure SNAT function to ensure that both source and destination-initiated traffic lands on the same firewall instance. Furthermore, since native deployment requires an IPsec VPN which limits its performance to 1Gbps, in this scenario a single firewall instance can only perform at 500Mbps since the VPN function is traversed twice.

A more detailed functional comparison is described in the table below.

Both primary and HA FireNet Gateways attach its eth1 ENI to the AWS TGW. When AWS TGW forwards packets to the FireNet VPC/VNet, it applies AZ affinity in the best effort manner. That is, packets coming from a source VPC/VNet instance in AZ-a will be forwarded to the gateway whose ENI is in AZ-a.

For example, assume there are two FireNet gateways, gateway-1 and gateway-2. One has eth1 in AZ-a and the other is in AZ-b. In a healthy state, both gateways receive traffic from the AWS TGW. Spoke VPC/VNet traffic from AZ-a will be forwarded to gateway-1 eth1 ENI for processing. Spoke VPC/VNet traffic from AZ-b will be forwarded to gateway-2 for processing.

When gateway-1 goes down, the Controller detects the failure, and then the Controller reprograms the default route entry (0.0.0.0/0) of the route table that is associated with the gateway-1 eth1 subnet (with the name like -gw-tgw-ingress) to point to the ENI of eth1 of the gateway-2 (its subnet should have a name like -gw-hagw-tgw-ingress), thus redirecting all AZ-a source traffic to the gateway in AZ-b.

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 enter the CIDRs in the field "Network List Excluded From East-West Inspection" to exclude them from being inspected by the firewall.

Aviatrix FireNet gateway failure detection time is 8 - 10 seconds. The switch over to alternative gateway (primary or backup) is about the same time.

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.

The Controller can also check firewall instance health on its LAN interface.

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.

If the FireNet deployment is for both Egress and Ingress traffic, you need to SNAT on the firewall instance to its LAN or Trusted Interface IP (eth2 interface). The rule is that for a source IP address that comes from NLB or a vendor load balancer such as F5 private IP address, it is translated to firewall interface eth2 private IP address.

Native FireNet refers to a deployment scenario where Aviatrix FireNet gateways are not deployed.

To migrate, use the following steps in the Aviatrix Controller: