Planning Your FireNet Implementation

Aviatrix Network Domains work with FireNet

Aviatrix Network Domain builds on the AWS Transit Gateway (TGW) route domain concepts. It provides isolation and segmentation between VPC/VNets. With Aviatrix Network 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 Network Domain with a Firewall Domain attribute.

  2. If a Network Domain has a connection policy to the Firewall Domain, then traffic going in and out of each VPC/VNet member in that Network 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, you can specify inspection based on pairs of Connection Policies. See Connection-based inspection.

Use Cases for FireNet

Case 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 Network Domain where this VPC/VNet is attached. Specify a connection policy for this Network Domain to connect to the Firewall Domain. All packets to and from this VPC/VNet will be inspected.

Case 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 Network Domain that all of these VPC/VNets are attached to. Then use a connection policy to connect this domain to the firewall domain.

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

The 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 caps each firewall instance 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.

Intra Domain Inspection

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

Aviatrix Transit FireNet for AWS and Azure

Aviatrix Transit FireNet allows you to deploy firewall 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.

transit_firenet

When deployed in Azure, Transit FireNet also works when using Native Azure VNet Spokes, as shown below.

transit_firenet_vnet

When deployed in Azure, only two firewall instances are supported.

Design Patterns

Hybrid to On-prem

hybrid

Hybrid with High Performance Encryption Mode

FireNet supports High Performance Encryption Mode.

insane

FireNet in Multi-Regions

multi-regions

Two Firewall Networks

You can deploy two Firewall Networks, one dedicated for East-West traffic inspection and another for egress inspection.

You must follow this configuration sequence:

  1. Disable the Traffic Inspection of the FireNet Gateway intended for egress control.

  2. Enable Egress Control for FireNet Gateway intended for egress control.

  3. Build connection policies.

dual_firenet

Aviatrix FQDN in FireNet for Egress Control

When an Aviatrix FQDN gateway is deployed in a VPC/VNet, it uses a public IP address to perform both whitelisting and NAT function for Internet-bound traffic. Sometimes these Internet bound traffic are partner API calls and these partners require to limit the number of IP addresses for each customer of theirs. In such situations, you can deploy FQDN in a centralized manner as shown in the diagram below.

fqdn_egress

Central Egress in a Multi-Region Deployment

Since the default routes are propagated over the Aviatrix Transit Gateway peering, you can consolidate the Internet-bound egress traffic to the firewalls in one region, as shown in the diagram below.

central_egress

Distributed Egress in a Multi Region Deployment

If you need to have a distributed egress for each region, make sure you filter out the default route 0.0.0.0/0 when you build the Aviatrix Transit Gateway peering, as shown in the diagram below.

multi_egress

Ingress Protection via Aviatrix Transit FireNet

This Ingress Protection design pattern is to have the traffic forward to firewall instances directly in Aviatrix Transit FireNet VPC/VNet as shown in the diagram below. In this design pattern, each firewall instance must configure (1) SNAT on its LAN interface that connects to the Aviatrix FireNet Gateway and (2) DNAT to the IP of application server/load balancer. The drawback of this design is that the source IP address is not preserved when traffic reaches the application.

For an example configuration workflow, see Ingress Protection via Aviatrix Transit FireNet with FortiGate.

transit_firenet_ingress

Hybrid with TGW

FireNet supports AWS Transit Gateway (TGW), as shown below.

firenet_transit

Hybrid with High Performance Encryption Mode

FireNet supports AWS Transit (TGW) with High Performance Encryption Mode.

firenet_insane

Native TGW integration

This hybrid deployment uses the native AWS Direct Connect Gateway.

firenet

Multi Region Transit with Native TGW integration

Connect to on-prem with AWS Direct Connect Gateway (DXGW) and use the Aviatrix Edge gateway to connect to multiple regions.

multi_region_firewall

Multi-Region Transit with Aviatrix Edge

Connect to on-prem with an Aviatrix Edge gateway for both hybrid and multi-regions.

multi_region_aviatrix_edge

Two Firewall Networks

You can deploy two Firewall Networks, one dedicated to VPC-to-VPC traffic inspection and another for egress inspection.

  1. Disable Traffic Inspection of the FireNet domain intended for Egress control.

  2. Enable Egress Control for FireNet domain intended for Egress control.

  3. Build connection policies.

multi_firewall

Aviatrix FQDN in FireNet for Egress Control

When an Aviatrix FQDN gateway is deployed in a VPC, it uses a public IP address to perform both whitelisting and NAT functions for Internet bound traffic. Sometimes this Internet bound traffic is partner API calls and these partners need to limit the number of IP addresses for each customer. In such situations, you can deploy FQDN in a centralized manner as shown in the diagram below.

fqdn_in_firenet

Distributed Egress in a Multi Region Deployment

If you need to have a distributed egress for each region, make sure you filter out the default route 0.0.0.0/0 when you build the Aviatrix Transit Gateway peering, as shown in the diagram below.

multi_egress