Azure VNet Routing

In this post I want to summarize some information about how routing in Azure works. This topic is well documented from Microsoft.

Virtual network traffic routing
Learn about how Azure routes traffic between Azure, on-premises, and Internet resources. Azure automatically creates a route table for each subnet within an Azure virtual network and adds system default routes to the table. To learn more about virtual networks and subnets, see Virtual network overview. You can override some of Azure’s system routes with custom routes, and add additional custom routes to route tables. Azure routes outbound traffic from a subnet based on the routes in a subnet’s route table.
Source: https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview

Routing within an Azure VNet

Azure automatically creates system routes and assigns the routes to each subnet in a virtual network. You can’t create system routes, nor can you remove system routes, but you can override some system routes with custom routes. Azure creates default system routes for each subnet, and adds additional optional default routes to specific subnets, or every subnet, when you use specific Azure capabilities.

Default Routes

Each route contains an address prefix and next hop type. When traffic leaving a subnet is sent to an IP address within the address prefix of a route, the route that contains the prefix is the route Azure uses. Learn more about how Azure selects a route when multiple routes contain the same prefixes, or overlapping prefixes.

Whenever a virtual network is created, Azure automatically creates the following default system routes for each subnet within the virtual network:

The next hop types listed in the previous table represent how Azure routes traffic destined for the address prefix listed. Explanations for the next hop types follow:

• Virtual network: Routes traffic between address ranges within the address space of a virtual network. Azure creates a route with an address prefix that corresponds to each address range defined within the address space of a virtual network. If the virtual network address space has multiple address ranges defined, Azure creates an individual route for each address range. Azure automatically routes traffic between subnets using the routes created for each address range. You don’t need to define gateways for Azure to route traffic between subnets. Though a virtual network contains subnets, and each subnet has a defined address range, Azure does not create default routes for subnet address ranges, because each subnet address range is within an address range of the address space of a virtual network.
• Internet: Routes traffic specified by the address prefix to the Internet. The system default route specifies the 0.0.0.0/0 address prefix. If you don’t override Azure’s default routes, Azure routes traffic for any address not specified by an address range within a virtual network, to the Internet, with one exception. If the destination address is for one of Azure’s services, Azure routes the traffic directly to the service over Azure’s backbone network, rather than routing the traffic to the Internet. Traffic between Azure services does not traverse the Internet, regardless of which Azure region the virtual network exists in, or which Azure region an instance of the Azure service is deployed in. You can override Azure’s default system route for the 0.0.0.0/0 address prefix with a custom route.
• None: Traffic routed to the None next hop type is dropped, rather than routed outside the subnet. Azure automatically creates default routes for the following address prefixes:
  • 10.0.0.0/8 and 192.168.0.0/16: Reserved for private use in RFC 1918.
  • 100.64.0.0/10: Reserved in RFC 6598.If you assign any of the previous address ranges within the address space of a virtual network, Azure automatically changes the next hop type for the route from None to Virtual network. If you assign an address range to the address space of a virtual network that includes, but isn’t the same as, one of the four reserved address prefixes, Azure removes the route for the prefix and adds a route for the address prefix you added, with Virtual network as the next hop type.

Source: https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview#default

Routing between Azure VNet and your on-premise Network

An on-premises network gateway can exchange routes with an Azure virtual network gateway using the border gateway protocol (BGP). Using BGP with an Azure virtual network gateway is dependent on the type you selected when you created the gateway. If the type you selected were:

• ExpressRoute: You must use BGP to advertise on-premises routes to the Microsoft Edge router. You cannot create user-defined routes to force traffic to the ExpressRoute virtual network gateway if you deploy a virtual network gateway deployed as type: ExpressRoute. You can use user-defined routes for forcing traffic from the Express Route to, for example, a Network Virtual Appliance.
• VPN: You can, optionally use BGP. For details, see BGP with site-to-site VPN connections.

When you exchange routes with Azure using BGP, a separate route is added to the route table of all subnets in a virtual network for each advertised prefix. The route is added with virtual network gateway listed as the source and next hop type.

Here you can see on my pfSense on-premise VPN Gateway, that the 4. entry with the route to the 172.16.0.0/16 network (my Azure VNet) is advertised from a different connected BGP peer, which is my lab network in Azure. Under Path you can see the AS number from the Azure BGP peer which is 65515 (Private ASN reserved by Azure).

Further you can see this advertised route (prefix) from the Azure BGP peer, under Diagnostics -> Routes in pfSense.

All advertised routes from other peers will have the number 1 as suffix in the Flags column as follows.

You can also check the same on the Azure site.

Therefore we can use PowerShell or Azure CLI.

To check the state we can use the following command

Where braintesting.de is the resource group
VpnGW-braintesting.de the virtual network gateway name
and peer the on-premises BGP peer IP address.

 The Local Network Gateway represents your onPrem VPN Gateway in Azure.

$ az network vnet-gateway list-bgp-peer-status -g braintesting.de -n VPNGW-braintesting.de --peer 10.0.0.252

To show the learned routes you can execute the following command

Where braintesting.de is the resource group
VpnGW-braintesting.de the virtual network gateway name
and peer the on-premises BGP peer IP address.

$ az network vnet-gateway list-learned-routes -g braintesting.de -n VpnGW-braintesting.de

Further you can check what routes will be advertised from Azure to your on-premise network by using the following PowerShell command.

Where braintesting.de is the resource group
VpnGW-braintesting.de the virtual network gateway name
and peer the on-premises BGP peer IP address.

Get-AzureRmVirtualNetworkGatewayAdvertisedRoute -VirtualNetworkGatewayName "VpnGW-braintesting.de" -ResourceGroupName "braintesting.de" -Peer "10.0.0.252"

In the following post I will use a route-based S2S VPN Tunnel and BGP which will advertise the static routes to each

In the following post I will use a policy-based S2S VPN Tunnel where I have to configure for each subnet on both sites a IPSec phase 2 tunnel.

How Azure selects a route

When outbound traffic is sent from a subnet, Azure selects a route based on the destination IP address, using the longest prefix match algorithm. For example, a route table has two routes: One route specifies the 10.0.0.0/24 address prefix, while the other route specifies the 10.0.0.0/16 address prefix. Azure routes traffic destined for 10.0.0.5, to the next hop type specified in the route with the 10.0.0.0/24 address prefix, because 10.0.0.0/24 is a longer prefix than 10.0.0.0/16, even though 10.0.0.5 is within both address prefixes. Azure routes traffic destined to 10.0.1.5, to the next hop type specified in the route with the 10.0.0.0/16 address prefix, because 10.0.1.5 isn’t included in the 10.0.0.0/24 address prefix, therefore the route with the 10.0.0.0/16 address prefix is the longest prefix that matches.

If multiple routes contain the same address prefix, Azure selects the route type, based on the following priority:

1. User-defined route
2. BGP route
3. System route

System routes for traffic related to virtual network, virtual network peerings, or virtual network service endpoints, are preferred routes, even if BGP routes are more specific.

For example, a route table contains the following routes:

When traffic is destined for an IP address outside the address prefixes of any other routes in the route table, Azure selects the route with the User source, because user-defined routes are higher priority than system default routes.

See Routing example for a comprehensive routing table with explanations of the routes in the table.

Source: https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview#how-azure-selects-a-route

0.0.0.0/0 address prefix

A route with the 0.0.0.0/0 address prefix instructs Azure how to route traffic destined for an IP address that is not within the address prefix of any other route in a subnet’s route table. When a subnet is created, Azure creates a default route to the 0.0.0.0/0 address prefix, with the Internet next hop type. If you don’t override this route, Azure routes all traffic destined to IP addresses not included in the address prefix of any other route, to the Internet. The exception is that traffic to the public IP addresses of Azure services remains on the Azure backbone network, and is not routed to the Internet. If you override this route, with a custom route, traffic destined to addresses not within the address prefixes of any other route in the route table is sent to a network virtual appliance or virtual network gateway, depending on which you specify in a custom route.

Determine Effective Routes for a Virtual Machine in Azure

To determine the effective routes for a virtual machine in Azure, you can use the Azure Portal or PowerShell.

For the Azure Portal, select your VM and click within the Settings section on Networking and here on the network interface. (vm-sub20805 in my case)

On the menu from the network interface click within the Help section on Effective routes to see the routes for your VM.

The first entry in the effective routes for this VM with the address prefix 172.16.0.0/16 (my VNet) is the default system route with the Next Hop IP Address in the form of a service tag named Virtual Network.

Virtual network: Routes traffic between address ranges within the address space of a virtual network. Azure creates a route with an address prefix that corresponds to each address range defined within the address space of a virtual network. If the virtual network address space has multiple address ranges defined, Azure creates an individual route for each address range. Azure automatically routes traffic between subnets using the routes created for each address range. You don’t need to define gateways for Azure to route traffic between subnets. Though a virtual network contains subnets, and each subnet has a defined address range, Azure does not create default routes for subnet address ranges, because each subnet address range is within an address range of the address space of a virtual network.

The second entry with the address prefix 192.168.196.0/24 (one of my on-premises subnets) was advertised by the BGP protocol and from my on-premises IPSec VPN gateway to my Azure virtual network gateway. Therefore the source is virtual network gateway. The Next Hop IP Address is Virtual network gateway 20.73.8.200 from Azure which is connected through an IPSec site-to-site VPN tunnel with my on-premises lab environment.

Virtual network gateway: One or more routes with Virtual network gateway listed as the next hop type are added when a virtual network gateway is added to a virtual network. The source is also virtual network gateway, because the gateway adds the routes to the subnet. If your on-premises network gateway exchanges border gateway protocol (BGP) routes with an Azure virtual network gateway, a route is added for each route propagated from the on-premises network gateway. It’s recommended that you summarize on-premises routes to the largest address ranges possible, so the fewest number of routes are propagated to an Azure virtual network gateway. There are limits to the number of routes you can propagate to an Azure virtual network gateway. For details, see Azure limits.

Depending on the Capabilities you enable in Azure, there are several more types of routing entries like the following below:

• Internet: Routes traffic specified by the address prefix to the Internet. The system default route specifies the 0.0.0.0/0 address prefix. If you don’t override Azure’s default routes, Azure routes traffic for any address not specified by an address range within a virtual network, to the Internet, with one exception. If the destination address is for one of Azure’s services, Azure routes the traffic directly to the service over Azure’s backbone network, rather than routing the traffic to the Internet. Traffic between Azure services does not traverse the Internet, regardless of which Azure region the virtual network exists in, or which Azure region an instance of the Azure service is deployed in. You can override Azure’s default system route for the 0.0.0.0/0 address prefix with a custom route.

• None: Traffic routed to the None next hop type is dropped, rather than routed outside the subnet. Azure automatically creates default routes for the following address prefixes:
  • 10.0.0.0/8 and 192.168.0.0/16: Reserved for private use in RFC 1918.
  • 100.64.0.0/10: Reserved in RFC 6598.If you assign any of the previous address ranges within the address space of a virtual network, Azure automatically changes the next hop type for the route from None to Virtual network. If you assign an address range to the address space of a virtual network that includes, but isn’t the same as, one of the four reserved address prefixes, Azure removes the route for the prefix and adds a route for the address prefix you added, with Virtual network as the next hop type.

• Virtual network (VNet) peering: When you create a virtual network peering between two virtual networks, a route is added for each address range within the address space of each virtual network a peering is created for. Learn more about virtual network peering.
  
  (VNet peering works within the same Azure region and also between different Azure regions, further you could peer VNets from different subscriptions and even from different tenants.)
  
  About how to peer two VNets from different tenants you can read my following post https://blog.matrixpost.net/vnet-peering-between-different-azure-active-directory-tenants/
  
  
  
• VirtualNetworkServiceEndpoint: The public IP addresses for certain services are added to the route table by Azure when you enable a service endpoint to the service. Service endpoints are enabled for individual subnets within a virtual network, so the route is only added to the route table of a subnet a service endpoint is enabled for. The public IP addresses of Azure services change periodically. Azure manages the addresses in the route table automatically when the addresses change. Learn more about virtual network service endpoints, and the services you can create service endpoints for.
  
  Note: The VNet peering and VirtualNetworkServiceEndpoint next hop types are only added to route tables of subnets within virtual networks created through the Azure Resource Manager deployment model. The next hop types are not added to route tables that are associated to virtual network subnets created through the classic deployment model. Learn more about Azure deployment models.

As mentioned above we can also use PowerShell to determine the effective routes from a virtual machine.

Adjust the parameters NetworkInterfaceName and ResourceGroupName for your environment.

Get-AzEffectiveRouteTable `
  -NetworkInterfaceName vm-sub20805 `
  -ResourceGroupName VMS `
  | Format-Table

Source: https://docs.microsoft.com/en-us/azure/virtual-network/diagnose-network-routing-problem#diagnose-using-powershell

Azure Route Tables

Azure automatically routes traffic between Azure subnets, virtual networks, and on-premises networks.

If you want to change any of Azure’s default routing, you do so by creating a route table.

There’s a limit to how many route tables you can create per Azure location and subscription. For details, see Networking limits – Azure Resource Manager.

If you plan to associate the route table to a subnet in a virtual network that’s connected to your on-premises network through a VPN gateway, and you don’t want to propagate your on-premises routes to the network interfaces in the subnet, set Virtual network gateway route propagation to Disabled.

Source: https://docs.microsoft.com/en-us/azure/virtual-network/manage-route-table#create-a-route

Associate a route table to a subnet

You can optionally associate a route table to a subnet. A route table can be associated to zero or more subnets.

Because route tables aren’t associated to virtual networks, you must associate a route table to each subnet you want the route table associated to.

Azure routes all traffic leaving the subnet based on routes you’ve created within route tables, default routes, and routes propagated from an on-premises network, if the virtual network is connected to an Azure virtual network gateway (ExpressRoute or VPN). You can only associate a route table to subnets in virtual networks that exist in the same Azure location and subscription as the route table.

1. Go to the Azure portal to manage your virtual network. Search for and select Virtual networks.
2. In the virtual network list, choose the virtual network that contains the subnet you want to associate a route table to.
3. In the virtual network menu bar, choose Subnets.
4. Select the subnet you want to associate the route table to.
5. In Route table, choose the route table you want to associate to the subnet.
6. Select Save.

If your virtual network is connected to an Azure VPN gateway, don’t associate a route table to the gateway subnet that includes a route with a destination of 0.0.0.0/0. Doing so can prevent the gateway from functioning properly. For more information about using 0.0.0.0/0 in a route, see Virtual network traffic routing.

So by default you don’t need to create and associate a route table to your Azure VNet subnets.

As you can see for example, the effective routes for my virtual machine VM-Sub20, will include a route for the address prefix 0.0.0.0/0 with the next hop IP address 20.73.8.200 from the type Virtual network gateway. This is my virtual network gateway which connects my on-premise network through an IPSec site-to-site VPN tunnel.

This will route all traffic destined for an IP address outside the address prefixes of any other routes in the route table and therefore will function as default gateway.

So all traffic destined to the internet is routed from my Azure virtual machine VM-Sub20 through my on-premises network.

Now if I want to change that behavior and want to route traffic to the internet directly out from Azure, I can use the previously created route table Sub20-routes, associated to the subnet from my virtual machine, to route traffic out directly from Azure to the internet as follows.

At the moment the public IP from the Azure VM will be the one from my on-premise network in the lab environment. The pubic IP 217.110.216.190 is the public IP on the WAN interface from the on-premise VPN Gateway.

So I add a route to the Internet which should route traffic destined to the internet directly out from Azure and not through the virtual network gateway and therefore through my on-premises network.

After that traffic destined for the internet will be routed directly and immediately out from Azure without any interaction on the VM. This will affect all systems homed in the subnet the route table is associated to.

Source: https://docs.microsoft.com/en-us/azure/virtual-network/manage-route-table#associate-a-route-table-to-a-subnet

Default outbound access for VMs in Azure will be retired on 30 September 2025 – How to transition to an explicit method of public connectivity

In my following post you will see how you can provide an explicit outbound internet access for your virtual machines.

Links

Virtual network traffic routing
https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview

IPSec dynamic route-based S2S VPN Tunnel between pfSense and an Azure VNet
https://blog.matrixpost.net/ipsec-dynamic-route-based-s2s-vpn-tunnel-between-pfsense-and-an-azure-vnet/

Azure Virtual Network frequently asked questions (FAQ)
https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-faq

Virtual network peering
https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview

VNet Security
https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-faq#security

Virtual network traffic routing
https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview