Using Subnet Inspection in Azure to Redirect Subnet-Level Traffic to Aviatrix Transit FireNet

Aviatrix’s subnet inspection feature allows you to redirect subnet-level traffic to the Aviatrix Transit FireNet Gateway for inspection by a firewall appliance such as Check Point, Palo Alto Firewall, or Fortinet FortiGate.

With this feature, you can assign subnets to a subnet group and enable an inspection policy for the subnet group. Traffic between subnets in different subnet groups with an inspection policy is then redirected to the firewall for inspection. Previously traffic inspection policies could only be applied at the VNet level, which meant that traffic from all subnets in a VNet would be inspected by the firewall.

The subnet inspection feature is currently only available for Azure.

Supported Features

The following features are supported when subnet groups are enabled.

Intra-VNet and Inter-VNet traffic inspection
ActiveMesh 2.0
High Performance Encryption (HPE)
Transit FireNet High Availability (HA) mode
Supported firewalls: Palo Alto Networks, Check Point, Fortinet
Terraform

Unsupported Features

The following features are not supported when subnet groups are enabled.

Egress FireNet Inspection (Dual Transit FireNet)
Azure Secondary CIDR not supported

Disabled Features

The following features are not supported and are disabled when subnet groups are enabled.

Customized SNAT on Spoke gateway
Customized Spoke advertised CIDRs
Customized Spoke VPC Route Table
Filter Learned Routes to Spoke VPC
Auto-advertised Spoke Site2Cloud CIDRs
BGP on Spoke

What is a Subnet Group?

A subnet group defines a logical grouping of subnets in a VNet. A subnet group is local to a VNet and does not span across multiple VNets. Traffic between subnets in the same subnet group flows through the Azure native virtual network and is not inspected by the firewall in the Aviatrix Transit FireNet configuration. If you want to inspect traffic between subnets in the same VNet, the subnets must be in different subnet groups.

Traffic Traversal in Subnet Groups

When subnet groups are created in a VNet, traffic from the subnet groups is redirected to the Aviatrix Transit FireNet Gateway for inspection, if you enable the inspection policy for the subnet groups.

Traffic for subnets that are part of a subnet group but do not have an inspection policy traverse the Aviatrix Transit FireNet gateway but are not redirected to or inspected by the firewall.

Intra-VNet Subnet Inspection for Subnets in the same Subnet Group

Traffic between VMs in the same subnet or subnet group is not inspected. If you want to inspect traffic between VMs in different subnets in the same VNet, the subnets must be in different subnet groups. For more information, refer to Connectivity Scenarios Between VMs in Subnets.

The diagrams in the scenarios below show single gateways for brevity. High Availability (HA) configuration is supported for Spoke and Transit FireNet gateways.

Intra-VNet Subnet Inspection

Inter-VNet Subnet Inspection Over a Shared Transit FireNet

Single Region Inter-VNet Subnet Inspection Over Transit Peering

In this scenario, the blue and green subnet groups have an inspection policy, and the orange subnet group does not. The traffic between the blue and green subnet groups traverses the firewall on either side. Since the orange subnet group does not have an inspection policy, the traffic between the orange and green subnet groups is not inspected by the firewall connected to the Transit FireNet to which the orange subnet group’s Spoke is attached. However, since the green subnet group has an inspection policy, the traffic between the orange and green subnet group traverses the firewall connected to the peer Transit FireNet.

Multi-Region Inter-VNet Subnet Inspection Over Transit Peering

The traffic traversal is similar to the Inter-VNet Subnet Inspection Over Transit Peering scenario.

Connectivity Scenarios Between VMs in Subnets

The following tables list different scenarios for connectivity between VMs in subnets that you need to consider when using subnet groups.

Intra-VNet Subnet Inspection

VM in Subnet A	VM in Subnet B	Connectivity Between VMs	Comment
Not in a subnet group	Not in a subnet group	Yes
Not in a subnet group	In a subnet group	No	Subnet A must be in a subnet group for connectivity; you must configure a default subnet group. See Important Recommendations.
In a subnet group	In a subnet group	Yes	Subnets can either be in the same or different subnet groups.

VM in Subnet A

VM in Subnet B

Connectivity Between VMs

Comment

Not in a subnet group

Yes

Not in a subnet group

In a subnet group

Subnet A must be in a subnet group for connectivity; you must configure a default subnet group. See Important Recommendations.

In a subnet group

Yes

Subnets can either be in the same or different subnet groups.

Inter-VNet Subnet Inspection

VM in Subnet A	VM in Subnet B	Connectivity Between VMs	Comment
Not in a subnet group	Not in a subnet group	Yes	Only if VNet B has no configured subnet groups. See Important Recommendations.
In a subnet group	Not in a subnet group	No	Only if VNet B has no configured subnet groups. See Important Recommendations.
In a subnet group	In a subnet group	Yes	Subnets can either be in the same or different subnet groups.

VM in Subnet A

VM in Subnet B

Connectivity Between VMs

Comment

Not in a subnet group

Yes

Only if VNet B has no configured subnet groups. See Important Recommendations.

In a subnet group

Not in a subnet group

Only if VNet B has no configured subnet groups. See Important Recommendations.

In a subnet group

Yes

Subnets can either be in the same or different subnet groups.

Inter-VNet Subnet Inspection over Transit Peering

The connection behavior is the same as Inter-VNet Subnet Inspection.

VM in Subnet A	VM in Subnet B	Connectivity Between VMs	Comment
Not in a subnet group	Not in a subnet group	Yes	Only if VNet B has no configured subnet groups.
In a subnet group	Not in a subnet group	No	Only if VNet B has no subnet groups configured. See Important Recommendations; configure a default subnet group.
In a subnet group	In a subnet group	Yes	Subnets can either be in the same or different subnet groups.

VM in Subnet A

VM in Subnet B

Connectivity Between VMs

Comment

Not in a subnet group

Yes

Only if VNet B has no configured subnet groups.

In a subnet group

Not in a subnet group

Only if VNet B has no subnet groups configured. See Important Recommendations; configure a default subnet group.

In a subnet group

Yes

Subnets can either be in the same or different subnet groups.

Important Recommendations

There is a downtime of 10 – 20 seconds when you add or remove subnets from a subnet group. If this downtime is not acceptable, be sure to add or remove subnet groups during a maintenance window.
For connectivity between VMs in different subnets, the subnets must be in different subnet groups. For subnets that do not need an inspection policy, create a subnet group named default, and add the subnets to the default subnet group. All other subnets that require traffic inspection and have an inspection policy set, add the subnets to custom subnet groups.
Only learned and Aviatrix-created routes are carried over from the subnet routing tables to the subnet group routing tables created by Aviatrix. Once a subnet is added to a group, you can manually recreate custom routes in the subnet group route table through the Azure console.

Configuring Azure Spoke Subnet Groups

For Azure-based Transit FireNet Gateways that have Spoke Gateways attached, you can use the Azure Spoke Subnet Groups dialog to add Azure Spoke Subnet Groups to these attached Spoke Gateways.

You cannot add Azure Spoke Subnet Groups to a Spoke Gateway that has inspection enabled.

You must remove Azure Spoke Subnet Groups from Azure Transit Gateways before removing FireNet functionality from those gateways.

Adding Azure Spoke Subnet Groups

When you add an Azure Spoke subnet group, selecting the Spoke Gateway automatically synchronizes the Subnet(s) list with the Azure portal so that the list is refreshed with any new subnets for this Spoke Gateway.

On the Security > FireNet > FireNet Gateways tab, click the name of an Azure FireNet Gateway that has at least one Spoke Gateway attached.
Click the Policy tab.
Click Azure Spoke Subnet Groups.
In the Azure Spoke Subnet Groups dialog, you can:
- Edit or delete an existing subnet group (if editing, you can only add or remove a subnet group; if deleting, you are prompted if you want to delete the subnet group)
- Add a Subnet Group
If adding a subnet group, click +Azure Spoke Subnet Group.
Enter a name for the Subnet Group.
Select the Spoke Gateway (only Spoke Gateways attached to this Transit FireNet are available). The Subnet(s) list is automatically refreshed with any new subnets for this Spoke Gateway from the Azure portal.
Select the Subnet Group(s).
Click Save. It may take a couple of minutes for the changes to save.
After the changes are saved, click Close to close the Create Azure Spoke Subnet Group dialog.
The new subnet group is displayed on the Azure Spoke Subnet Groups dialog.

Adding Inspection Policy for Spoke Subnet Group

After your new subnet groups are created, you can add them to the inspection policy for this particular Azure Transit FireNet gateway.

Select the Spoke Subnet Group in the Policy list.
Click Add in the Actions list.

See Configuring FireNet Inspection Policies for more information.

Removing Spoke Subnet Groups

Disable inspection for the Spoke Subnet Group by selecting the group on the FireNet Gateways > Policy tab and then selecting Remove from the Actions menu.
On the Policy tab, click Azure Spoke Subnet Groups.
In the Azure Spoke Subnet Groups dialog, select the delete icon next to the subnet group.
Click Delete to confirm that you want to delete the subnet group.
When the deletion is complete, click Close to close the dialog.