Aviatrix Default Route Handling

This document explains how Aviatrix handles the default route starting from R6.2.

Public Subnet vs. Private Subnet

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 pointing to IGW, the subnet is a public subnet. On the other hand, if 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 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.

Aviatrix definition table 1



Public cloud subnet/route table to IGW

UDR does not exist

UDR is associated with a subnet:

  • UDR: entry doesn’t exist

  • UDR: to Cloud Internet

Private cloud subnet/route table route entry does not exist

UDR is associated with a subnet: to non-Aviatrix NVA

  • UDR: to None to VGW

  • UDR: to non-Aviatrix NVA to TGW

  • UDR: to Virtual Network to AWS NAT gateway

  • UDR: to Virtual Network Gateway

overall: to non-IGW


IGW: Internet gateways

UDR: User Defined Routing

NVA: Network Virtual Appliance

NVA: Network Virtual Appliance

VGW: Virtual private gateway

TGW: AWS Transit Gateway


In Azure, the rule of thumb of classifying a subnet as private is that the subnet’s associated route table has a UDR (User Defined Routes) route entry of pointing to None, an NVA appliance, Virtual Network or Virtual Network Gateway.

Changes Made on Azure in R6.2

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.


Use the Useful Tool “create a VPC tool” to create an Spoke and Transit Azure VNet. For Spoke VNet, the Controller will program a UDR default route pointing to next hop type “None” to the route table associated with the private subnets. Check Create a VPC for more info.

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

Use Case: Single SNAT or FQDN in a VPC/VNet

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

Rule 4.1: Overwrite default route entry in subnet/route table where Aviatrix defines it as “Private” when the below features are enabled:


  • Single SNAT

  • FQDN discovery

  • FQDN

High-level logic:

  • Utilize the definition in this document above to discover private subnet/route table

  • Save customer’s original route entry configuration

  • Overwrite route entry to Aviatrix

  • Restore back customer’s original route entry configuration if users disable the above features

Rule 4.2: Load balance the route entry between Aviatrix gateways when users attempt to enable the same type of feature such as Single SNAT/FQDN which is already deployed in the same network.

Use Case: Aviatrix Centralized Egress or On-Prem Advertising Default Route

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 route to Aviatrix spoke gateways, and program 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.

How does Aviatrix Define a Public or Private Subnet/Route Table in Each Cloud, and What are the Rules/Scenarios for Use Case 2?

Here, we only discuss AWS and Azure.

Aviatrix definition table 2



Public cloud subnet/route table to IGW

UDR does not exist

UDR is associated with a subnet:

  • UDR: entry doesn’t exist

  • UDR: to Cloud Internet

Private cloud subnet/route table route entry does not exist

UDR is associated with a subnet:

  • UDR: to None

  • UDR: to Virtual Network

Rule 5.1: Aviatrix Transit Gateway on route


  • Learning default route from on-prem

  • Learning default route from Aviatrix Transit peering

  • Enabling Central Egress feature

High-level logic:

  • Utilize the Aviatrix definition table 2 above to discover private subnet/route table

  • Program ‘ to Aviatrix Spoke Gateway’ into private subnet/route table of Spoke network, but it has a slightly different implementation for each cloud as below table.

  • Program ‘ to Aviatrix Transit Gateway’ into private subnet/route table of Spoke network by following Azure implementation as below table if Azure ARM Spoke through Native Peering feature is deployed

Aviatrix definition



Private cloud subnet/route table

Silently ignore if there is a route existed.

Silently ignore most of the route if it is existed, but Aviatrix overwrites the default route as follows:

Aviatrix does NOT overwrite in this case.

  • UDR: to None

  • UDR: to Virtual Network

Rule 5.2: Error out a warning message when users attempt to enable single SNAT/FQDN in a Spoke network where default route is already programmed by Rule 3.1.


If there is a default route learned from on-prem already existed in Aviatrix Transit solution, then Aviatrix will pop out a warning message when users attempt to enable single SNAT/FQDN features in Spoke network.