Diagnose a virtual machine routing problem

In this article, you learn how to diagnose a routing problem by viewing the routes that are effective for a network interface in a virtual machine (VM). Azure creates several default routes for each virtual network subnet. You can override Azure's default routes by defining routes in a route table, and then associating the route table to a subnet. The combination of routes you create, Azure's default routes, and any routes propagated from your on-premises network through an Azure VPN gateway (if your virtual network is connected to your on-premises network) via the border gateway protocol (BGP), are the effective routes for all network interfaces in a subnet. If you're not familiar with virtual network, network interface, or routing concepts, see Virtual network overview, Network interface, and Routing overview.

Scenario

You attempt to connect to a VM, but the connection fails. To determine why you can't connect to the VM, you can view the effective routes for a network interface using the Azure portal, PowerShell, or the Azure CLI.

The steps that follow assume you have an existing VM to view the effective routes for. If you don't have an existing VM, first deploy a Linux or Windows VM to complete the tasks in this article with. The examples in this article are for a VM named myVM with a network interface named myVMNic1. The VM and network interface are in a resource group named myResourceGroup, and are in the China East region. Change the values in the steps, as appropriate, for the VM you are diagnosing the problem for.

Diagnose using Azure portal

1. Log into the Azure portal with an Azure account that has the necessary permissions.

2. At the top of the Azure portal, enter the name of a VM that is in the running state, in the search box. When the name of the VM appears in the search results, select it.

3. Under Settings on the left, select Networking, and navigate to the network interface resource by selecting its name.

4. On the left, select Effective routes. The effective routes for a network interface named myVMNic1 are shown, in the following picture:

   If there are multiple network interfaces attached to the VM, you can view the effective routes for any network interface by selecting it. Since each network interface can be in a different subnet, each network interface can have different effective routes.

   In the example shown in the previous picture, the listed routes are default routes that Azure creates for each subnet. Your list has at least these routes, but may have additional routes, depending on capabilities you may have enabled for your virtual network such as it being peered with another virtual network or connected to your on-premises network through an Azure VPN gateway. To learn more about each of the routes, and other routes you may see for your network interface, see Virtual network traffic routing. If your list has a large number of routes, you may find it easier to select Download, to download a .csv file with the list of routes.

Though effective routes were viewed through the VM in the previous steps, you can also view effective routes through an:

• Individual network interface: Learn how to view a network interface.
• Individual route table: Learn how to view a route table.

Diagnose using PowerShell

You can run the commands by running PowerShell from your computer. If you run PowerShell from your computer, you need the Azure PowerShell module, version 1.0.0 or later. Run Get-Module -ListAvailable Az on your computer, to find the installed version. If you need to upgrade, see Install Azure PowerShell module. If you are running PowerShell locally, you also need to run Connect-AzAccount -Environment AzureChinaCloud to log into Azure with an account that has the necessary permissions.

Get the effective routes for a network interface with Get-AzEffectiveRouteTable. The following example gets the effective routes for a network interface named myVMNic1, that is in a resource group named myResourceGroup:

Get-AzEffectiveRouteTable `
  -NetworkInterfaceName myVMNic1 `
  -ResourceGroupName myResourceGroup `
  | Format-Table

To understand the information returned in the output, see Routing overview. Output is only returned if the VM is in the running state. If there are multiple network interfaces attached to the VM, you can review the effective routes for each network interface. Since each network interface can be in a different subnet, each network interface can have different effective routes. If you're still having a communication problem, see additional diagnosis and considerations.

If you don't know the name of a network interface, but do know the name of the VM the network interface is attached to, the following commands return the IDs of all network interfaces attached to a VM:

$VM = Get-AzVM -Name myVM `
  -ResourceGroupName myResourceGroup
$VM.NetworkProfile

You receive output similar to the following example:

NetworkInterfaces
-----------------
{/subscriptions/<ID>/resourceGroups/myResourceGroup/providers/Microsoft.Network/networkInterfaces/myVMNic1

In the previous output, the network interface name is myVMNic1.

Diagnose using Azure CLI

You can run the commands by running the CLI from your computer. This article requires the Azure CLI version 2.0.32 or later. Run az --version to find the installed version. If you need to install or upgrade, see Install Azure CLI. If you are running the Azure CLI locally, you also need to run az login and log into Azure with an account that has the necessary permissions.

Get the effective routes for a network interface with az network nic show-effective-route-table. The following example gets the effective routes for a network interface named myVMNic1 that is in a resource group named myResourceGroup:

az network nic show-effective-route-table \
  --name myVMNic1 \
  --resource-group myResourceGroup

To understand the information returned in the output, see Routing overview. Output is only returned if the VM is in the running state. If there are multiple network interfaces attached to the VM, you can review the effective routes for each network interface. Since each network interface can be in a different subnet, each network interface can have different effective routes. If you're still having a communication problem, see additional diagnosis and considerations.

If you don't know the name of a network interface, but do know the name of the VM the network interface is attached to, the following commands return the IDs of all network interfaces attached to a VM:

az vm show \
  --name myVM \
  --resource-group myResourceGroup

Resolve a problem

Resolving routing problems typically consists of:

• Adding a custom route to override one of Azure's default routes. Learn how to add a custom route.
• Change or remove a custom route that may cause routing to an undesired location. Learn how to change or delete a custom route.
• Ensuring that the route table that contains any custom routes you've defined is associated to the subnet the network interface is in. Learn how to associate a route table to a subnet.
• Ensuring that devices such as Azure VPN gateway or network virtual appliances you've deployed are operable. Use the VPN diagnostics capability of Network Watcher to determine any problems with an Azure VPN gateway.

If you're still having communication problems, see Considerations and Additional diagnosis.

Considerations

Consider the following points when troubleshooting communication problems:

• Routing is based on longest prefix match (LPM) among routes that you've defined, border gateway protocol (BGP), and system routes. If there is more than one route with the same LPM match, then a route is selected based on its origin in the order listed in Routing overview. With effective routes, you can only see effective routes that are an LPM match, based on all the available routes. Seeing how the routes are evaluated for a network interface makes it a lot easier to troubleshoot specific routes that may be impacting communication from your VM.
• If you've defined custom routes to a network virtual appliance (NVA), with Virtual Appliance as the next hop type, ensure that IP forwarding is enabled on the NVA receiving the traffic, or packets are dropped. Learn more about enabling IP forwarding for a network interface. Additionally, the operating system, or application within the NVA must also be able to forward network traffic and be configured to do so.
• If you've created a route to 0.0.0.0/0, all outbound internet traffic is routed to the next hop you specified, such as to an NVA or VPN gateway. Creating such a route is often referred to as forced tunneling. Remote connections using the RDP or SSH protocols from the internet to your VM may not work with this route, depending on how the next hop handles the traffic. Forced-tunneling can be enabled:
  • When using site-to-site VPN, by creating a route with a next hop type of VPN Gateway. Learn more about configuring forced tunneling.
  • If a 0.0.0.0/0 (default route) is advertised over BGP through a virtual network gateway when using a site-to-site VPN, or ExpressRoute circuit. Learn more about using BGP with a site-to-site VPN or ExpressRoute.
• For virtual network peering traffic to work correctly, a system route with a next hop type of VNet Peering must exist for the peered virtual network's prefix range. If such a route doesn't exist, and the virtual network peering link is Connected:
  • Wait a few seconds, and retry. If it's a newly established peering link, it occasionally takes longer to propagate routes to all the network interfaces in a subnet. To learn more about virtual network peering, see Virtual network peering overview and manage virtual network peering.
  • Network security group rules may be impacting communication. For more information, see Diagnose a virtual machine network traffic filter problem.
• Though Azure assigns default routes to each Azure network interface, if you have multiple network interfaces attached to the VM, only the primary network interface is assigned a default route (0.0.0.0/0), or gateway, within the VM's operating system. Learn how to create a default route for secondary network interfaces attached to a Windows or Linux VM. Learn more about primary and secondary network interfaces.

Additional diagnosis

• To run a quick test to determine the next hop type for traffic destined to a location, use the Next hop capability of Azure Network Watcher. Next hop tells you what the next hop type is for traffic destined to a specified location.
• If there are no routes causing a VM's network communication to fail, the problem may be due to firewall software running within the VM's operating system
• If you are force tunneling traffic to an on-premises device through a VPN gateway, or NVA, you may not be able to connect to a VM from the internet, depending on how you've configured routing for the devices. Confirm that the routing you have configured for the device routes traffic to either a public or private IP address for the VM.
• Use the connection troubleshoot capability of Network Watcher to determine routing, filtering, and in-OS causes of outbound communication problems.

Next steps

• Learn about all tasks, properties, and settings for a route table and routes.
• Learn about all next hop types, system routes, and how Azure selects a route.