Virtual Network Traffic Routing
- Roger Cruz
Intro
Documentation
Tips and Tidbits
Azure automatically creates a route table for each subnet within an Azure virtual network and adds system default routes to the table.
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.
Custom routes are helpful when, for example, you want to route traffic between subnets through a network virtual appliance (NVA).
For the NVA, you must enable IP forwarding in Azure for its network interface.
In addition, you must also enable IP forwarding in the operating system of the virtual machine.: How To: Enable IP Forwarding In Windows To Allow Gateway Routing
Any network interface attached to a virtual machine that forwards network traffic to an address other than its own must have the Azure Enable IP forwarding option enabled for it.
The setting disables Azure's check of the source and destination for a network interface.
Learn more about how to enable IP forwarding for a network interface.
System and Default Routes
Azure automatically creates system routes and assigns the routes to each subnet in a virtual network.
You can't create or 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.
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.
Whenever a virtual network is created, Azure automatically creates the following default system routes for each subnet within the 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.
Azure automatically routes traffic between subnets using the routes created for each address range.
Internet: Routes traffic specified by the address prefix to the Internet.
The system default route specifies the 0.0.0.0/0 address prefix.
Azure routes traffic for any address not specified by an address range within a virtual network to the Internet, unless the destination address is for an Azure service.
Azure routes any traffic destined for its service directly to the service over the backbone network, rather than routing the traffic to the Internet.
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 (
Shared Address Space address range).
Depending on the capability, Azure adds optional default routes to either specific subnets within the virtual network, or to all subnets within a virtual network.
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.
Virtual network gateway: When you add a virtual network gateway to a virtual network, Azure adds one or more routes with Virtual network gateway as the next hop type.
The source is listed as 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.
There are limits to the number of routes you can propagate to an Azure virtual network gateway, so you should summarize on-premises routes to the largest address ranges possible.
VirtualNetworkServiceEndpoint: Azure adds the public IP addresses for certain services to the route table 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.
Custom routes
You can override the default routes that Azure creates by using your own user-defined routes (UDR).
useful when you want to ensure that traffic between two subnets passes through a firewall appliance, or if you want to ensure that no traffic from a VNet could be routed to the internet.
Each subnet can have zero or one associated route table.
When you create a route table and associate it to a subnet, the routes within it are combined with, or override, the default routes Azure adds to a subnet.
You can specify the following next hop types when creating a user-defined route:
Virtual appliance: A virtual appliance is a virtual machine that typically runs a network application, such as a firewall.
NVAs are VMs that help with network functions like routing and firewall optimization.
When you create a route with the virtual appliance hop type, you also specify a next hop IP address. The IP address can be:
The private IP address of a network interface attached to a virtual machine.
The private IP address of an Azure internal load balancer.
Virtual network gateway: Specify when you want traffic destined for specific address prefixes routed to a virtual network gateway.
The virtual network gateway must be created with type VPN.
None: Specify when you want to drop traffic to an address prefix, rather than forwarding the traffic to a destination.
Virtual network: Specify when you want to override the default routing within a virtual network.
Internet: Specify when you want to explicitly route traffic destined to an address prefix to the Internet, or if you want traffic destined for Azure services with public IP addresses kept within the Azure backbone network.
Add Custom Routes By Creating A Routing Table
Create a route table when you need to override Azure’s default routing.
For example, you can route traffic to a network virtual appliance or to your on-premises network for inspection.
A route table contains routes and is associated to one or more subjects.
Routes are automatically added to the route table for all subnets with Virtual network gateway propagation enabled.
Add Custom Routes
The address prefix is for a range that you want to capture and send to another place. For example, any address in a subnet’s range of the Private subnet at 10.0.1.0/24.
The last step in our example is to associate the Public subnet with the new routing table.
Each subnet can have zero or one route table associated to it.
the virtual appliance shouldn't have a public IP address and IP forwarding should be enabled.
Diagnose a routing problem
You can diagnose a routing problem by viewing the routes that are effective for a network interface in a VM.
The effective routes for all network interfaces in a subnet are the combination of routes you create, Azure's default routes, and any routes propagated from your on-premises network through an Azure VPN gateway via the border gateway protocol (BGP).
Since each network interface can be in a different subnet, each network interface can have different effective routes.
output is only returned if the VM is in the running state.
Get-AzEffectiveRouteTable -NetworkInterfaceName myVMNic1 -ResourceGroupName myResourceGroup
Secure a VNet by using forced tunneling
Forced tunneling lets you redirect or "force" all Internet-bound traffic back to your on-premises location via a Site-to-Site VPN tunnel for inspection and auditing.
If you don't configure forced tunneling, Internet-bound traffic from your VMs in Azure always traverses from the Azure network infrastructure directly out to the Internet, without the option to allow you to inspect or audit the traffic.
Forced tunneling can be configured by using Azure PowerShell. It can't be configured using the Azure portal.
The Mid-tier and Backend subnets are forced tunneled.
Any outbound connections from these two subnets to the Internet will be forced or redirected back to an on-premises site via one of the Site-to-site (S2S) VPN tunnels.
Forced tunneling is configured using virtual network custom user-defined routes.
To configure forced tunneling, you must:
Create a routing table.
Add a user-defined default route to the VPN Gateway.
Associate the routing table to the appropriate VNet subnet(s).
Forced tunneling must be associated with a VNet that has a route-based VPN gateway.
You must set a default site connection among the cross-premises local sites connected to the virtual network.
The on-premises VPN device must be configured using 0.0.0.0/0 as traffic selectors.