Quickstart: Diagnose a virtual machine network traffic filter problem - Azure CLI

In this quickstart you deploy a virtual machine (VM), and then check communications to an IP address and URL and from an IP address. You determine the cause of a communication failure and how you can resolve it.

If you don't have an Azure subscription, create a free account before you begin.

Open Azure Cloud Shell

Azure Cloud Shell is a free, interactive shell that you can use to run the steps in this article. Common Azure tools are preinstalled and configured in Cloud Shell for you to use with your account. Just select the Copy button to copy the code, paste it in Cloud Shell, and then press Enter to run it. There are a few ways to open Cloud Shell:

Select Try It in the upper-right corner of a code block. Cloud Shell in this article
Open Cloud Shell in your browser. https://shell.azure.com/bash
Select the Cloud Shell button on the menu in the upper-right corner of the Azure portal. Cloud Shell in the portal

If you choose to install and use the CLI locally, this quickstart requires that you are running the Azure CLI version 2.0.28 or later. To find the installed version, run az --version. If you need to install or upgrade, see Install Azure CLI 2.0. After you verify the CLI version, run az login to create a connection with Azure. The CLI commands in this quickstart are formatted to run in a Bash shell.

Create a VM

Before you can create a VM, you must create a resource group to contain the VM. Create a resource group with az group create. The following example creates a resource group named myResourceGroup in the eastus location:

az group create --name myResourceGroup --location eastus

Create a VM with az vm create. If SSH keys do not already exist in a default key location, the command creates them. To use a specific set of keys, use the --ssh-key-value option. The following example creates a VM named myVm:

az vm create \
  --resource-group myResourceGroup \
  --name myVm \
  --image UbuntuLTS \
  --generate-ssh-keys

The VM takes a few minutes to create. Don't continue with remaining steps until the VM is created and the CLI returns output.

Test network communication

To test network communication with Network Watcher, you must first enable a network watcher in the region the VM that you want to test is in, and then use Network Watcher's IP flow verify capability to test communication.

Enable network watcher

If you already have a network watcher enabled in the East US region, skip to Use IP flow verify. Use the az network watcher configure command to create a network watcher in the EastUS region:

az network watcher configure \
  --resource-group NetworkWatcherRG \
  --locations eastus \
  --enabled

Use IP flow verify

When you create a VM, Azure allows and denies network traffic to and from the VM, by default. You might later override Azure's defaults, allowing or denying additional types of traffic. To test whether traffic is allowed or denied to different destinations and from a source IP address, use the az network watcher test-ip-flow command.

Test outbound communication from the VM to one of the IP addresses for www.bing.com:

az network watcher test-ip-flow \
  --direction outbound \
  --local 10.0.0.4:60000 \
  --protocol TCP \
  --remote 13.107.21.200:80 \
  --vm myVm \
  --nic myVmVMNic \
  --resource-group myResourceGroup \
  --out table

After several seconds, the result returned informs you that access is allowed by a security rule named AllowInternetOutbound.

Test outbound communication from the VM to 172.31.0.100:

az network watcher test-ip-flow \
  --direction outbound \
  --local 10.0.0.4:60000 \
  --protocol TCP \
  --remote 172.31.0.100:80 \
  --vm myVm \
  --nic myVmVMNic \
  --resource-group myResourceGroup \
  --out table

The result returned informs you that access is denied by a security rule named DefaultOutboundDenyAll.

Test inbound communication to the VM from 172.31.0.100:

az network watcher test-ip-flow \
  --direction inbound \
  --local 10.0.0.4:80 \
  --protocol TCP \
  --remote 172.31.0.100:60000 \
  --vm myVm \
  --nic myVmVMNic \
  --resource-group myResourceGroup \
  --out table

The result returned informs you that access is denied because of a security rule named DefaultInboundDenyAll. Now that you know which security rules are allowing or denying traffic to or from a VM, you can determine how to resolve the problems.

View details of a security rule

To determine why the rules in Use IP flow verify are allowing or preventing communication, review the effective security rules for the network interface with the az network nic list-effective-nsg command:

az network nic list-effective-nsg \
  --resource-group myResourceGroup \
  --name myVmVMNic

The returned output includes the following text for the AllowInternetOutbound rule that allowed outbound access to www.bing.com in a previous step under Use IP flow verify:

{
 "access": "Allow",
 "additionalProperties": {},
 "destinationAddressPrefix": "Internet",
 "destinationAddressPrefixes": [
  "Internet"
 ],
 "destinationPortRange": "0-65535",
 "destinationPortRanges": [
  "0-65535"
 ],
 "direction": "Outbound",
 "expandedDestinationAddressPrefix": [
  "1.0.0.0/8",
  "2.0.0.0/7",
  "4.0.0.0/6",
  "8.0.0.0/7",
  "11.0.0.0/8",
  "12.0.0.0/6",
  ...
 ],
 "expandedSourceAddressPrefix": null,
 "name": "defaultSecurityRules/AllowInternetOutBound",
 "priority": 65001,
 "protocol": "All",
 "sourceAddressPrefix": "0.0.0.0/0",
 "sourceAddressPrefixes": [
  "0.0.0.0/0"
 ],
 "sourcePortRange": "0-65535",
 "sourcePortRanges": [
  "0-65535"
 ]
},

You can see in the previous output that destinationAddressPrefix is Internet. It's not clear how 13.107.21.200 relates to Internet though. You see several address prefixes listed under expandedDestinationAddressPrefix. One of the prefixes in the list is 12.0.0.0/6, which encompasses the 12.0.0.1-15.255.255.254 range of IP addresses. Since 13.107.21.200 is within that address range, the AllowInternetOutBound rule allows the outbound traffic. Additionally, there are no higher priority (lower number) rules shown in the previous output that override this rule. To deny outbound communication to an IP address, you could add a security rule with a higher priority, that denies port 80 outbound to the IP address.

When you ran the az network watcher test-ip-flow command to test outbound communication to 172.131.0.100 in Use IP flow verify, the output informed you that the DefaultOutboundDenyAll rule denied the communication. The DefaultOutboundDenyAll rule equates to the DenyAllOutBound rule listed in the following output from the az network nic list-effective-nsg command:

{
 "access": "Deny",
 "additionalProperties": {},
 "destinationAddressPrefix": "0.0.0.0/0",
 "destinationAddressPrefixes": [
  "0.0.0.0/0"
 ],
 "destinationPortRange": "0-65535",
 "destinationPortRanges": [
  "0-65535"
 ],
 "direction": "Outbound",
 "expandedDestinationAddressPrefix": null,
 "expandedSourceAddressPrefix": null,
 "name": "defaultSecurityRules/DenyAllOutBound",
 "priority": 65500,
 "protocol": "All",
 "sourceAddressPrefix": "0.0.0.0/0",
 "sourceAddressPrefixes": [
  "0.0.0.0/0"
 ],
 "sourcePortRange": "0-65535",
 "sourcePortRanges": [
  "0-65535"
 ]
}

The rule lists 0.0.0.0/0 as the destinationAddressPrefix. The rule denies the outbound communication to 172.131.0.100, because the address is not within the destinationAddressPrefix of any of the other outbound rules in the output from the az network nic list-effective-nsg command. To allow the outbound communication, you could add a security rule with a higher priority, that allows outbound traffic to port 80 at 172.131.0.100.

When you ran the az network watcher test-ip-flow command in Use IP flow verify to test inbound communication from 172.131.0.100, the output informed you that the DefaultInboundDenyAll rule denied the communication. The DefaultInboundDenyAll rule equates to the DenyAllInBound rule listed in the following output from the az network nic list-effective-nsg command:

{
 "access": "Deny",
 "additionalProperties": {},
 "destinationAddressPrefix": "0.0.0.0/0",
 "destinationAddressPrefixes": [
  "0.0.0.0/0"
 ],
 "destinationPortRange": "0-65535",
 "destinationPortRanges": [
  "0-65535"
 ],
 "direction": "Inbound",
 "expandedDestinationAddressPrefix": null,
 "expandedSourceAddressPrefix": null,
 "name": "defaultSecurityRules/DenyAllInBound",
 "priority": 65500,
 "protocol": "All",
 "sourceAddressPrefix": "0.0.0.0/0",
 "sourceAddressPrefixes": [
  "0.0.0.0/0"
 ],
 "sourcePortRange": "0-65535",
 "sourcePortRanges": [
  "0-65535"
 ]
},

The DenyAllInBound rule is applied because, as shown in the output, no other higher priority rule exists in the output from the az network nic list-effective-nsg command that allows port 80 inbound to the VM from 172.131.0.100. To allow the inbound communication, you could add a security rule with a higher priority that allows port 80 inbound from 172.131.0.100.

The checks in this quickstart tested Azure configuration. If the checks return expected results and you still have network problems, ensure that you don't have a firewall between your VM and the endpoint you're communicating with and that the operating system in your VM doesn't have a firewall that is allowing or denying communication.

Clean up resources

When no longer needed, you can use az group delete to remove the resource group and all of the resources it contains:

az group delete --name myResourceGroup --yes

Next steps

In this quickstart, you created a VM and diagnosed inbound and outbound network traffic filters. You learned that network security group rules allow or deny traffic to and from a VM. Learn more about security rules and how to create security rules.

Even with the proper network traffic filters in place, communication to a VM can still fail, due to routing configuration. To learn how to diagnose VM network routing problems, see Diagnose VM routing problems or, to diagnose outbound routing, latency, and traffic filtering problems, with one tool, see Connection troubleshoot.