You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -31,21 +31,19 @@ Log in to the Azure portal at https://portal.azure.com.
31
31
## Create a VM
32
32
33
33
1. Select **+ Create a resource** found on the upper, left corner of the Azure portal.
34
-
2. Select **Compute**, and then select **Windows Server 2016 Datacenter** or a version of **Ubuntu Server**.
35
-
3. Enter, or select, the following information, accept the defaults for the remaining settings, and then select **OK**:
34
+
1. Select **Compute**, and then select **Windows Server 2019 Datacenter** or a version of **Ubuntu Server**.
35
+
1. Enter, or select, the following information, accept the defaults for the remaining settings, and then select **OK**:
36
36
37
37
|Setting|Value|
38
38
|---|---|
39
-
|Name|myVm|
40
-
|User name| Enter a user name of your choosing.|
41
-
|Password| Enter a password of your choosing. The password must be at least 12 characters long and meet the defined complexity requirements.|
42
39
|Subscription| Select your subscription.|
43
40
|Resource group| Select **Create new** and enter **myResourceGroup**.|
44
-
|Location| Select **East US**|
41
+
|Virtual machine name|myVm|
42
+
|Region| Select **East US**|
43
+
|User name| Enter a user name of your choosing.|
44
+
|Password| Enter a password of your choosing. The password must be at least 12 characters long and meet the defined complexity requirements.|
45
45
46
-
4. Select a size for the VM and then select **Select**.
47
-
5. Under **Settings**, accept all the defaults, and select **OK**.
48
-
6. Under **Create** of the **Summary**, select **Create** to start VM deployment. The VM takes a few minutes to deploy. Wait for the VM to finish deploying before continuing with the remaining steps.
46
+
1. Select **Review + create** to start VM deployment. The VM takes a few minutes to deploy. Wait for the VM to finish deploying before continuing with the remaining steps.
49
47
50
48
## Test network communication
51
49
@@ -55,25 +53,24 @@ To test network communication with Network Watcher, first enable a network watch
55
53
56
54
If you already have a network watcher enabled in at least one region, skip to the [Use IP flow verify](#use-ip-flow-verify).
57
55
58
-
1. In the portal, select **All services**. In the **Filter box**, enter *Network Watcher*. When **Network Watcher** appears in the results, select it.
59
-
2. Enable a network watcher in the East US region, because that's the region the VM was deployed to in a previous step. Select **Regions**, to expand it, and then select **...** to the right of **East US**, as shown in the following picture:
1. In the **Home** portal, select **More services**. In the **Filter box**, enter *Network Watcher*. When **Network Watcher** appears in the results, select it.
57
+
1. Enable a network watcher in the East US region, because that's the region the VM was deployed to in a previous step. Select **Add**, to expand it, and then select **Region** under **Subscription**, as shown in the following picture:
58
+
:::image type="content" source="./media/diagnose-vm-network-traffic-filtering-problem/enable-network-watcher.png" alt-text="Screenshot of how to Enable Network Watcher.":::
59
+
1. Select your region then select **Add**.
64
60
65
61
### Use IP flow verify
66
62
67
63
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.
68
64
69
-
1. In the portal, select **All services**. In the **All services***Filter* box, enter *Network Watcher*. When **Network Watcher** appears in the results, select it.
70
-
2. Select **IP flow verify**, under **NETWORK DIAGNOSTIC TOOLS**.
71
-
3. Select your subscription, enter or select the following values, and then select **Check**, as shown in the picture that follows:
65
+
1. In the **Home**portal, select **More services**. In the **All services***Filter* box, enter *Network Watcher*. When **Network Watcher** appears in the results, select it.
66
+
1. Select **IP flow verify**, under **Network diagnostic tools**.
67
+
1. Select your subscription, enter or select the following values, and then select **Check**, as shown in the picture that follows:
72
68
73
69
|Setting |Value |
74
70
|--------- |--------- |
75
-
| Resource group | Select myResourceGroup |
76
-
| Virtual machine | Select myVm |
71
+
| Subscription | Select your subscription |
72
+
| Resource group | Select **myResourceGroup**|
73
+
| Virtual machine | Select **myVm**|
77
74
| Network interface | myvm - The name of the network interface the portal created when you created the VM is different. |
78
75
| Protocol | TCP |
79
76
| Direction | Outbound |
@@ -82,29 +79,32 @@ When you create a VM, Azure allows and denies network traffic to and from the VM
82
79
| Remote IP address | 13.107.21.200 - One of the addresses for <www.bing.com>. |
:::image type="content" source="./media/diagnose-vm-network-traffic-filtering-problem/ip-flow-verify-outbound.png" alt-text="Screenshot of values to input in IP flow verify.":::
86
83
87
84
After a few seconds, the result returned informs you that access is allowed because of a security rule named **AllowInternetOutbound**. When you ran the check, Network Watcher automatically created a network watcher in the East US region, if you had an existing network watcher in a region other than the East US region before you ran the check.
88
-
4. Complete step 3 again, but change the **Remote IP address** to **172.31.0.100**. The result returned informs you that access is denied because of a security rule named **DefaultOutboundDenyAll**.
89
-
5. Complete step 3 again, but change the **Direction** to **Inbound**, the **Local port** to **80** and the **Remote port** to **60000**. The result returned informs you that access is denied because of a security rule named **DefaultInboundDenyAll**.
85
+
1. Complete step 3 again, but change the **Remote IP address** to **172.31.0.100**. The result returned informs you that access is denied because of a security rule named **DenyAllOutBound**.
86
+
1. Complete step 3 again, but change the **Direction** to **Inbound**, the **Local port** to **80** and the **Remote port** to **60000**. **Remote IP address** remains **172.31.0.100**. The result returned informs you that access is denied because of a security rule named **DenyAllInBound**.
90
87
91
88
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.
92
89
93
90
## View details of a security rule
94
91
95
-
1. To determine why the rules in steps 3-5 of **Use IP flow verify** allow or deny communication, review the effective security rules for the network interface in the VM. In the search box at the top of the portal, enter *myvm*. When the **myvm** (or whatever the name of your network interface is) network interface appears in the search results, select it.
96
-
2. Select **Effective security rules** under **SUPPORT + TROUBLESHOOTING**, as shown in the following picture:
92
+
To determine why the rules in steps 3-5 of **Use IP flow verify** allow or deny communication, review the effective security rules for the network interface in the VM.
1. In the search box at the top of the portal, enter *myvm*. When the **myvm Regular Network Interface** appears in the search results, select it.
95
+
1. Select **Effective security rules** under **Support + troubleshooting**, as shown in the following picture:
96
+
97
+
:::image type="content" source="./media/diagnose-vm-network-traffic-filtering-problem/effective-security-rules.png" alt-text="Screenshot of Effective security rules.":::
99
98
100
-
In step 3 of **Use IP flow verify**, you learned that the reason the communication was allowed is because of the **AllowInternetOutbound** rule. You can see in the previous picture that the **DESTINATION** for the rule is **Internet**. It's not clear how 13.107.21.200, the address you tested in step 3 of **Use IP flow verify**, relates to **Internet** though.
101
-
3. Select the **AllowInternetOutBound** rule, and then select **Destination**, as shown in the following picture:
99
+
In step 3 of **Use IP flow verify**, you learned that the reason the communication was allowed is because of the **AllowInternetOutbound** rule. You can see in the previous picture that the **Destination** for the rule is **Internet**. It's not clear how 13.107.21.200, the address you tested in step 3 of **Use IP flow verify**, relates to **Internet** though.
100
+
1. Select the **AllowInternetOutBound** rule, and then scroll down to **Destination**, as shown in the following picture:
101
+
102
+
:::image type="content" source="./media/diagnose-vm-network-traffic-filtering-problem/security-rule-prefixes.png" alt-text="Screenshot of Security rule prefixes.":::
One of the prefixes in the list is **12.0.0.0/8**, 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 picture in step 2 that override this rule. Close the **Address prefixes** box. To deny outbound communication to 13.107.21.200, you could add a security rule with a higher priority, that denies port 80 outbound to the IP address.
104
105
105
-
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 picture in step 2 that override this rule. Close the **Address prefixes** box. To deny outbound communication to 13.107.21.200, you could add a security rule with a higher priority, that denies port 80 outbound to the IP address.
106
-
4. When you ran the outbound check to 172.131.0.100 in step 4 of **Use IP flow verify**, you learned that the **DefaultOutboundDenyAll** rule denied communication. That rule equates to the **DenyAllOutBound** rule shown in the picture in step 2 that specifies **0.0.0.0/0** as the **DESTINATION**. This rule denies the outbound communication to 172.131.0.100, because the address is not within the **DESTINATION** of any of the other **Outbound rules** shown in the picture. To allow the outbound communication, you could add a security rule with a higher priority, that allows outbound traffic to port 80 for the 172.131.0.100 address.
107
-
5. When you ran the inbound check from 172.131.0.100 in step 5 of **Use IP flow verify**, you learned that the **DefaultInboundDenyAll** rule denied communication. That rule equates to the **DenyAllInBound** rule shown in the picture in step 2. The **DenyAllInBound** rule is enforced because no other higher priority rule exists that allows port 80 inbound to the VM from 172.31.0.100. To allow the inbound communication, you could add a security rule with a higher priority, that allows port 80 inbound from 172.31.0.100.
106
+
1. When you ran the outbound check to 172.131.0.100 in step 4 of **Use IP flow verify**, you learned that the **DenyAllOutBound** rule denied communication. That rule equates to the **DenyAllOutBound** rule shown in the picture in step 2 that specifies **0.0.0.0/0** as the **Destination**. This rule denies the outbound communication to 172.131.0.100, because the address is not within the **Destination** of any of the other **Outbound rules** shown in the picture. To allow the outbound communication, you could add a security rule with a higher priority, that allows outbound traffic to port 80 for the 172.131.0.100 address.
107
+
1. When you ran the inbound check from 172.131.0.100 in step 5 of **Use IP flow verify**, you learned that the **DenyAllInBound** rule denied communication. That rule equates to the **DenyAllInBound** rule shown in the picture in step 2. The **DenyAllInBound** rule is enforced because no other higher priority rule exists that allows port 80 inbound to the VM from 172.31.0.100. To allow the inbound communication, you could add a security rule with a higher priority, that allows port 80 inbound from 172.31.0.100.
108
108
109
109
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.
110
110
@@ -113,8 +113,8 @@ The checks in this quickstart tested Azure configuration. If the checks return e
113
113
When no longer needed, delete the resource group and all of the resources it contains:
114
114
115
115
1. Enter *myResourceGroup* in the **Search** box at the top of the portal. When you see **myResourceGroup** in the search results, select it.
116
-
2. Select **Delete resource group**.
117
-
3. Enter *myResourceGroup* for **TYPE THE RESOURCE GROUP NAME:** and select **Delete**.
116
+
1. Select **Delete resource group**.
117
+
1. Enter *myResourceGroup* for **TYPE THE RESOURCE GROUP NAME:** and select **Delete**.
0 commit comments