When deploying virtual machine (VM) workloads into Azure Virtual Networks (VNets) and their associated subnets, the default routing behavior automatically takes effect unless customized routes are applied. This behavior is governed by Azure’s system routes, which are predefined routing entries associated with each subnet via a default route table. The system routes define how network traffic should be routed both within and outside of the VNet, depending on the destination network and the next hop.
The default route table consists of 18 system routes, each dictating specific routing logic. These routes ensure proper traffic flow to internal resources, external networks, and Azure services, while enforcing industry-standard routing practices and maintaining security by preventing certain types of traffic from being exposed to the public internet. Below, we explore the routing entries in the default route table and how they apply to various traffic scenarios within an Azure VNet.
The system routes in the default route table can be categorized into four primary groups, each serving a specific purpose in routing traffic efficiently and securely:
- Internal VNet Traffic (Next Hop: Virtual Network): The first entry in the default route table handles traffic between subnets within the same VNet. The Next Hop Type for this route is set to "Virtual Network," meaning that traffic destined for another internal VNet address will be routed internally using Azure's default VNet routing mechanism. Each subnet within the VNet has a default gateway (the first IP address of the subnet), which serves as the next hop for traffic originating from that subnet. When traffic needs to reach a resource in a different subnet, it first traverses the source subnet’s gateway, which then routes the traffic through the VNet to the destination subnet’s gateway, where it is forwarded to the target resource. For example, consider a scenario where a VM (WebVM) in a “WebTierSubnet” is communicating with a VM (DataVM) in a “DataTierSubnet”. The traffic would first be routed to WebTierSubnet’s default gateway and then forwarded across the VNet to DataTierSubnet’s gateway, ultimately reaching DataVM.
- Unspecified Traffic (Next Hop: Internet): The second entry in the route table defines how traffic is handled when no other specific routes apply. This is often referred to as the “default route”. In Azure’s default routing, any traffic that does not match another route entry is sent to the internet. The “Next Hop Type” for this route is set to "Internet," which directs traffic to Azure’s internet gateway. This allows outbound traffic to reach external destinations. However, there are important exceptions: traffic destined for Azure platform services (e.g., storage accounts, Azure SQL databases) with public IP addresses remains on Azure’s private backbone network rather than being routed through the public internet. This routing mechanism ensures that Azure services can be accessed with low latency and enhanced security. For instance, if “WebVM” attempts to reach an external IP address that is not covered by any other route, the traffic will be routed through Azure’s internet gateway and sent to the internet. However, traffic targeting an Azure service's public IP would stay within the Azure network infrastructure.
- Private IP Address Spaces (Next Hop: None): Some routing entries in the default route table ensures that traffic using private IP address ranges specified by “RFC 1918” (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16) is never routed to the internet. These private IP ranges are commonly used for internal networking and must be confined to the VNet or a connected network. The “Next Hop Type” for these routes is set to "None," meaning that any traffic destined for these private IP ranges is dropped. This is a standard practice followed by all Internet Service Providers (ISPs) to prevent private IP addresses from leaking onto the public internet. In Azure, this routing rule ensures that VMs or other resources using private IPs cannot inadvertently send traffic outside of the VNet.
- Carrier-Grade NAT IP Range (Next Hop: None): One routing entry in the route table ensures that the “RFC 6598” address space (100.64.0.0/10), which is used for Carrier-Grade NAT (CGNAT), is not routed to the internet. Similar to the private IP ranges in RFC 1918, this address space is reserved for internal use by ISPs and cloud providers like Azure. Traffic destined for this address space is dropped by the default route, as indicated by the “Next Hop Type” of "None." This prevents the RFC 6598 range from being exposed to external networks and ensures compliance with networking standards.
- Azure Management IPs (Next Hop: None): Some routing entries are designed to protect Azure’s management infrastructure. These entries ensure that Azure management public IP address ranges, which are used for platform services and control plane traffic, are not routed to the internet. Any traffic attempting to reach these IP ranges is dropped, as indicated with the “Next Hop Type” of "None." This layer of protection ensures that Azure’s internal management operations are isolated from customer traffic, adding an additional layer of security.
Beyond the default route table entries, additional system routes are dynamically added when specific Azure networking features are implemented. These include:
- VNet Peering: When VNets are peered, additional system routes are created to ensure that traffic between peered VNets is routed correctly, typically using the next hop type "Virtual Network."
- VNet Gateways: When a VNet is connected to on-premises networks via a VPN or ExpressRoute gateway, Azure adds routes to the default route table to ensure that traffic destined for on-premises resources is forwarded to the VNet gateway.
- Service Endpoints: When service endpoints are enabled for specific Azure services (e.g., Azure Storage, Azure SQL), routes are added to ensure that traffic for these services is routed via the Azure backbone network rather than the public internet.
