Firewall Network (FireNet) FAQ

What is Aviatrix Firewall Network (FireNet)?

Aviatrix Firewall Network (FireNet) is a turnkey network solution to deploy firewall instances in the cloud, as shown in the diagram below.

firewall_network

FireNet significantly simplifies firewall instance deployment and allows the firewall instances to inspect VPC/VNet to VPC/VNet (East West) traffic, VPC/VNet to Internet (Egress) traffic, and VPC/VNet to on-prem (North South) traffic.

In addition, FireNet allows you to scale firewall deployment to multiple AZs and multiple instances in active/active state.

How does Aviatrix FireNet compare with the native deployment in AWS Transit Gateway?

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.

firewall_deploy

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 instances by 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.

What are the Benefits of FireNet Deployment Model?

For enterprises that wish to deploy a firewall in any Cloud Service Provider (CSP) including AWS, Azure, GCP, or OCI, Aviatrix’s FireNet deployment model provides the best performance and automation.

  • Simplicity The Aviatrix Firewall Network significantly simplifies firewall deployment in the cloud while providing the maximum performance and scale.

  • Full Traffic Inspection With FireNet, North South (on-prem and cloud), East West (VPC/VNet to VPC/VNet) and Internet bound egress traffic can be inspected by firewall instances.

  • No IPsec Tunnels There are no IPsec tunnels connecting to firewall instances as opposed to ECMP VPN deployment model, maximizing each firewall instance throughput.

  • No SNAT SNAT function is not required to be performed by firewall instances for east west traffic inspection as opposed to the ECMP VPN deployment model, resulting in instances in Spoke VPC/VNets having complete visibility of source traffic.

  • No BGP The Firewall does not need to run BGP. All routes programming is done by the Controller through Palo Alto APIs.

  • Scale Out Multiple firewall instances can be deployed as a group to meet the demand of increasing workload.

  • Policy Driven Policy driven workflow allows you to customize which VPC/VNets traffic should be inspected.

  • Vendor Integration Launch Palo Alto Networks VM-Series from the Aviatrix Controller console to simplify deployment.

  • Automation The Aviatrix Controller automatically updates Palo Alto VM-Series route tables when on-prem route changes or VPC/VNet attachment changes.

Does FireNet support other firewalls?

The following firewalls are supported: - Palo Alto VM-Series - Check Point CloudGuard - Fortinet FortiGate

Does FireNet work with other firewall appliances?

Yes. FireNet solution has been validated to work with Checkpoint, FortiGate and Barracuda CloudGen Firewall.

How is Firewall Network different from Transit DMZ?

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.

How Does Aviatrix Security Domains work with FireNet?

Aviatrix Security Domain builds on the AWS Transit Gateway (TGW) route domain concepts. It provides isolation and segmentation between VPC/VNets. With Aviatrix Security Domains, you can create a group of VPC/VNets with similar security requirements.

There are situations where additional security measures such as packet inspection are required. That is, you need to deploy a firewall for certain VPC/VNets. FireNet provides the network solution that simplifies firewall deployment and scale.

  1. Deploy the Aviatrix FireNet in a special Security Domain with a Firewall Domain attribute.

  2. If a Security Domain has a connection policy to the Firewall Domain, then traffic going in and out of each VPC/VNet member in that Security Domain will first be forwarded to the Firewall for inspection. In other words, the connection policy specifies which domain (or a group of VPC/VNets) will be inspected by the firewall. See Domain-based inspection.

  3. Alternatively, starting in Release 6.3 you can specify inspection based on pairs of Connection Policies. See Connection-based inspection.

What are the use cases for FireNet?

Example 1. VPC/VNet with PCI data

If you have a VPC/VNet that deploys applications that host Personal Information or PCI data and your compliance requires packet inspection, you can create a Security Domain where this VPC/VNet is attached. Specify a connection policy for this Security Domain to connect to the Firewall Domain. All packets to and from this VPC/VNet will be inspected.

Example 2. Production VPC/VNets

You may decide to inspect all traffic from the production data, which resides in multiple VPC/VNets. In this case you can create a Security Domain that all of these VPC/VNets are attached to. Then use connection policy to connect this domain to the firewall domain.

What are the limitations of FireNet?

You can have multiple Firewall Domains. However, a Security 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.

How does FireNet compare with ECMP/VPN based firewall deployment?

AWS Transit Gateway (TGW) supports VPN with ECMP load balancing. With this capability, you can launch multiple firewall instances in a load balanced fashion for Egress Inspection and VPC/VNet to VPC/VNet traffic inspection.

One problem with this deployment is performance. The IPsec tunnel limits each firewall instance to be capped at 1Gbps. When this architecture is deployed for VPC/VNet to VPC/VNet inspection, traffic goes through the VGW (the other end of the IPsec tunnel) twice, further reducing its throughput to 500Mbps. What this implies is that each firewall instance can only operate at 400Mbps throughput. This is much lower than what firewall instances can do without an IPsec tunnel.

Another problem is that for east west traffic inspection, the firewall instance must NAT the source address, otherwise the return traffic is not guaranteed to go through the same firewall instance. This is because ECMP makes the independent decision of distributing the traffic of the firewall instances for each direction of the traffic.

What is the minimum gateway instance size for FireNet deployment?

The minimum gateway instance size is C5.xlarge. This is because the FireNet gateway requires 4 network interfaces:

  • eth0 as a management interface

  • eth1 as a TGW interface

  • eth2 as a firewall instance interface

  • eth3 as the HA FireNet gateway interface

The private interfaces on FireNet Gateway are described as below.

private_interfaces

Can TGW send packets to both FireNet Gateways?

Yes. Both primary and HA FireNet Gateways attach its eth1 ENI to TGW. When 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, two FireNet gateways, gateway-1 and gateway-2, one has eth1 in AZ-a and the other is in AZ-b, respectively. In a healthy state, both gateways receive traffic from TGW. A 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.

How does FireNet work?

Take, for example, a VPC/VNet1 to VPC/VNet2 traffic inspection, where VPC/VNet1 and VPC/VNet2 are attached to the same TGW.

As a packet from VPC/VNet1 arrives at the FireNet gateway via the TGW, it does a 4-tuple (source IP, destination IP, source port and destination port) hash calculation to decide if it should forward the packet to one of the associated firewall instances or forward to the HA FireNet gateway.

If the hash calculation determines the firewall instance is associated with the HA FireNet gateway, it forwards the packet to the HA FireNet gateway through its eth3 interface.

When the HA FireNet gateway receives the packet, it performs exactly the same hash calculation and decides which associated firewall instance it should forward the traffic to.

The packet flow is illustrated in the diagram below:

firenet_packet_flow

How do I configure FireNet?

Follow the FireNet workflow to deploy firewall in the cloud.

How do I enable Egress inspection on 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.

Note for GCE instances: Any GCE instance (excluding Controller-created gateways) that needs to participate in egress control (FQDN, SNAT, and FW Egress) have to be tagged as “avx-snat-noip.” The GCE network tag “avx-snat-noip” can be associated during GCE instance creation or by editing an existing instance.

How do I make Ingress inspection to work on FireNet?

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.

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.

Note:
  1. Maximum 20 CIDRs coma-separated are supported.

  2. CIDRs are excluded from East-West inspections only.

  3. In AWS TGW FireNet, if Egress inspection is enabled, Egress traffic originated from an excluded CIDRs will be dropped. If excluded CIDRs needs to be inspected then use a separate FireNet for Egress Traffic and separate FireNet for East-West Traffic.

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.

Follow the FireNet workflow to complete Steps 1, 2, 3, 4, 5, 6 and 8.

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

What is the maximum performance FireNet can achieve?

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.

firewall_network_perf

Are there any design patterns for Firewall Network deployment?

Yes, please refer to the Firewall Network Design Patterns.

Can VM-Series be launched with Bootstrap integration?

Yes. When you launch a VM-Series from Aviatrix Controller console, 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.

What is the FireNet gateway failover time?

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

Why does the primary gateway send packets to backup gateway instead of sending to firewall directly?

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 the different AZ and subnet, forwarding packets directly to the firewall instance requires AWS route table to be programmed with target as the firewall instance, and as a result, there cannot be more than one firewall instance in the different AZ, thus losing the scale out capability.

Does Aviatrix Controller communicate with Palo Alto Panorama to its private IP address?

Yes, if the Panorama is reachable via private IP.

Does Aviatrix Controller check the health of Panorama?

No. Aviatrix Controller only checks the health of VM-Series instances.

How does Aviatrix Controller know which Panorama is the primary one if there are two cross sites?

The primary IP address is configured at the Vendor Integration function.

Aviatrix FireNet Security Groups

On firewall LAN interface.

Eth2 on PAN; or Eth1 on Fortigate and Checkpoint. This interface accepts all data traffic to be inspected or going to the Internet (if egress is enabled). The traffic originates from an internal instance, which is destinated to another internal instance or the Internet. Therefore, it is OK 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 4 interfaces.

Eth0: this interface is used for all Internet traffic (DNS, NTP, etc), communication with the Controller (TCP, SSH, etc), encrypted tunnels, etc. This interface is under the Aviatrix Controller’s control, it’s SG is already limited to the minimum. User should NOT change it. Even if user changes it, the Aviatrix Controller will always try to change back.

Eth1: this interface is used to send/receive traffic to AWS TGW. It accepts data traffic from TGW, so it is OK to limit SG to RFC1918 only.

Eth2: this interface is used to send/receive traffic to firewalls (through firewall’s LAN interface), so it expects traffic originated from both internal and external. It might be OK to limit to RFC1918 since AWS SG is stateful.

Eth3: this interface is used to exchange traffic between primary and backup gateway, this is part of our uniform hashing algorithm. Like eth2, it expects traffic originated from both internal and external. It might be OK to limit to RFC1918, since AWS SG is stateful.

What are the integration points with Fortinet firewall?

  1. Managing Life Cycle of Fortinet firewall instances

    1. Aviatrix Controller launches and deletes Fortinet firewall instances.

    2. Supports Fortinet Bootstrap mechanism to simplifying firewall instance launching and preload any firewall configurations.

  2. Managing Fortinet firewall instances pool

    1. The Aviatrix Controller monitors individual firewall health by periodically pining the LAN interface of each firewall instances. Ping period is every 5 second with a 20ms ping time out. The failure detection is maximum 5 seconds and 40ms. The Aviatrix Controller automatically detaches a unhealthy firewall instance. When the firewall instance is reachable again, it automatically attaches it back to the pool.

    2. You can initiate a new firewall instance to be launched and attached to pool at any given time.

    3. You can initiate to remove a firewall instance from the pool at any given time.

  3. Static Route Configuration

    Currently there is no API integration to automatically populate Fortinet route table entries. Customer needs to configure these entries. We recommend configuring the 3 RFC 1918 routes to point to the firewall LAN interface. For FireNet deployment, the RFC 1918 routes should point to the LAN interface subnet cloud provider’s default gateways. For Transit FireNet deployment, the RFC 1918 routes should point to the FireNet Gateway LAN interface IP, as shown in this example..

What is Intra Domain inspection?

Intra Domain inspection allows traffic between VPC/VNets in the same Security Domain to be redirected to Firewall Domain for inspection before reaching to the destination.

How to migrate from FireNet to FireNet with AWS GWLB or vice versa?

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).

  1. Save firewall configuration.

  2. Disassociate firewall instance > Go to Aviatrix Controller > Firewall Network > Setup > Step 10.

  3. Delete firewall instance > Go to Aviatrix Controller > Firewall Network > Setup > Step 7a.

  4. Disable FireNet function > Go to Aviatrix Controller > Firewall Network > Step 11a to disable Aviatrix Gateway FireNet Function.

  5. Enable Transit FireNet function > Go to Aviatrix Controller > Firewall Network > Step 5a to enable the Aviatrix Gateway for FireNet Function. Mark the Use AWS GWLB checkbox if migrating from Aviatrix FireNet to FireNet with AWS GWLB.

  6. Launch and associate firewall > Go to Aviatrix Controller > Firewall Network > Step 7a.

  7. Restore firewall configuration.

Can we migrate from FireNet solution to Native FireNet with GWLB solution ?

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

To migrate, use the following steps for migration:

  1. Save the firewall configuration.

  2. Disassociate firewall instance > Go to Aviatrix Controller > Firewall Network > Setup > Step 10.

  3. Delete firewall instance > Go to Aviatrix Controller > Firewall Network > Setup > Step 7a.

  4. Disable FireNet function > Go to Aviatrix Controller > Firewall Network > Step 11a to disable Aviatrix Gateway FireNet Function.

  5. Delete Transit FireNet Gateway.

  6. Enable Transit FireNet function > Go to Aviatrix Controller > Firewall Network > Step 5b to enable the Native AWS GWLB for FireNet Function.

  7. Launch and associate firewall > Go to Aviatrix Controller > Firewall Network > Step 7a.

  8. Restore firewall configuration.