Aviatrix Default Route Handling

A public subnet is different from a private subnet in a VPC/VNet in each Cloud Service Provider (CSP) by way of how the default route is managed.

In AWS, a public subnet is well-defined. If the subnet associated route table has a route entry 0.0.0.0/0 pointing to IGW, the subnet is a public subnet. On the other hand, if 0.0.0.0/0 does not point to IGW, this is a private subnet.

In Azure, such distinction is less defined via explicit route entries. By default any VM in Azure is a public instance with direct Internet access and can be reached from the Internet as long as it has a public IP address. This is because Azure automatically programs a system route entry with 0.0.0.0/0 pointing to Internet, as shown in the screenshot below after a VM is launched. Azure’s "system programmed default route" is displayed in Effective Routes.

Since Aviatrix Controller programs route table extensively and there are use cases that deal with egress control, it is important that the Controller follow well-defined rules when handling different types of subnets.

Below are what Aviatrix Controller defines as public or private subnet.

Prior to 6.2, Aviatrix Controller blindly overwrites the default route to point to Aviatrix gateway in every route table whenever egress control is involved. This can cause outages if the deployment has public facing application or VMs. In 6.2, the rules for Aviatrix Controller to overwrite the default route becomes well defined.

If you created Azure VNet via create a VPC tool prior R6.2 or created Azure VNet via your own scrip, make sure you inject a UDR route 0.0.0.0 pointing to the next hop type "None" to signal to the Aviatrix Controller that this is a private subnet and its default route can be overwritten.

If you have already deploy Transit FireNet with Egress Control, upgrading to 6.2 does not impact the existing traffic. However if you detach a Spoke VNet and re-attach it or disable Egress Inspection and re-enable it, the new rules will kick in.

When testing egress control from a VM in Azure VNet, make sure this VM is on a private subnet as defined in this document. Since this VM is on a private subnet without a public IP address, you cannot directly SSH into the VM. You can use Azure Bastion Service or Aviatrix User VPN gateway to connect to the private IP address of the VM via SSH.

Users can launch Aviatrix Gateways within the network, and enable Single SNAT or FQDN feature on the gateway. Aviatrix gateway will discover 'private' subnets/route tables, then program default route 0.0.0.0/0 pointing to Aviatrix gateway into it. Furthermore, to reduce friction and to shorten downtime when users remove default route in their cloud environment by themselves, Aviatrix performs overwriting default route logic by default. By doing this, private instances/VMs internet traffic will go through Aviatrix gateway, and inspected by FQDN (if enabled).

In the Aviatrix Transit Network solution, for private instances/VMS in spoke networks, users can choose centralized egress by using Aviatrix FireNet, or using on-prem egress. In either case, Aviatrix transit gateway propagates 0.0.0.0/0 route to Aviatrix spoke gateways, and program 0.0.0.0/0 route in spoke private subnets/route tables. Thus, all private instance/VM’s internet traffic are forwarded to transit gateway, and then forwarded to FireNet or on-prem networks.

Cloud, and What are the Rules/Scenarios for Use Case 2?

Here, we only discuss AWS and Azure.