Troubleshooting Network Issues in Azure
Network connectivity failures in Azure are almost always caused by one of three things: an NSG rule blocking traffic, a missing or incorrect route, or a DNS resolution problem. Azure Network Watcher gives you specific tools to test each one without needing to deploy additional diagnostic VMs or install packet sniffers. This page walks through each tool with real CLI commands.
Enabling Network Watcher
Network Watcher is a regional service that must exist in each region where you want to use it. Azure usually creates it automatically when you deploy a VNet, but you can confirm and create it manually:
# Check if Network Watcher exists in eastus
az network watcher list --output table
# Create Network Watcher in a region if it doesn't exist
az network watcher configure \
--resource-group NetworkWatcherRG \
--locations eastus \
--enabled trueNetwork Watcher resources are placed in the NetworkWatcherRG resource group by default. This resource group is created automatically in most cases.
IP flow verify: is an NSG blocking this traffic?
IP flow verify tests whether a specific flow — defined by source IP, destination IP, port, protocol, and direction — would be allowed or denied by the NSGs applied to a VM’s NIC. It returns the allow/deny verdict and which specific rule produced it.
Example: testing whether outbound TCP 443 from a VM to a specific IP is allowed:
# Get the VM's resource ID
VM_ID=$(az vm show \
--name vm-app-01 \
--resource-group rg-spoke-app \
--query id \
--output tsv)
# Test if TCP 443 outbound is allowed to 8.8.8.8
az network watcher test-ip-flow \
--direction Outbound \
--local 10.0.2.4:443 \
--remote 8.8.8.8:443 \
--protocol TCP \
--vm $VM_IDThe output shows Allow or Deny and the name of the rule that produced the result. If you see Deny and a rule name, go fix or override that specific rule.
Test inbound traffic (checking if port 3389 from the internet is blocked):
az network watcher test-ip-flow \
--direction Inbound \
--local 10.0.2.4:3389 \
--remote 203.0.113.50:56789 \
--protocol TCP \
--vm $VM_IDChecking effective NSG rules on a NIC
A VM’s NIC can have two NSGs applied: one from the subnet and one directly on the NIC. The effective security rules command shows all rules from both NSGs combined, in the order they are evaluated:
# Get the NIC name from the VM
NIC_NAME=$(az vm show \
--name vm-app-01 \
--resource-group rg-spoke-app \
--query "networkProfile.networkInterfaces[0].id" \
--output tsv | awk -F'/' '{print $NF}')
# Show effective security rules on the NIC
az network nic show-effective-nsg \
--name $NIC_NAME \
--resource-group rg-spoke-app \
--output tableThe output lists every effective rule: its priority, direction, source, destination, port, protocol, and access (Allow/Deny). This is the complete picture of what the NSG will do to traffic arriving at or leaving this NIC.
Look for unexpected allow rules at low priority numbers (like 100 or 200) that might be overly permissive, and verify the deny rules at the bottom are present. If the default deny rules (priority 65000+) are missing, the NSG was misconfigured.
Next hop: diagnosing routing problems
The next hop tool tells you where Azure would route a packet from a specific VM to a specific destination IP. It shows the next hop type and IP, which tells you whether traffic is going to the internet, a VNet appliance (like Azure Firewall), or being dropped.
# Check where traffic from vm-app-01 to 8.8.8.8 is routed
az network watcher show-next-hop \
--resource-group rg-spoke-app \
--vm vm-app-01 \
--source-ip 10.0.2.4 \
--dest-ip 8.8.8.8Possible next hop types and what they mean:
| Next hop type | Meaning |
|---|---|
| Internet | Traffic goes directly to the internet (no forced tunneling) |
| VirtualAppliance | Traffic is sent to a virtual appliance (Azure Firewall, NVA) — check the IP shown |
| VirtualNetworkGateway | Traffic is sent to a VPN or ExpressRoute gateway (hybrid connectivity) |
| VnetLocal | Traffic stays within the VNet (correct for internal destinations) |
| None | No route — traffic is dropped. This is a routing problem. |
If you expected traffic to go to a VPN Gateway (for on-premises connectivity) but next hop shows Internet, a User Defined Route is missing or incorrect. If next hop shows None, there is no route for that destination at all.
Connection troubleshoot: end-to-end connectivity test
Connection troubleshoot performs an end-to-end connectivity check from a source VM to a destination (another VM, a URL, or an IP:port combination). It tests through NSGs, routing, and reports whether the connection succeeded and the round-trip latency:
# Test TCP connectivity from vm-app-01 to a database VM on port 1433
az network watcher test-connectivity \
--resource-group rg-spoke-app \
--source-resource vm-app-01 \
--dest-resource vm-db-01 \
--dest-port 1433 \
--protocol TCP
# Test connectivity to a public URL
az network watcher test-connectivity \
--resource-group rg-spoke-app \
--source-resource vm-app-01 \
--dest-address "https://management.azure.com" \
--dest-port 443The output includes whether the connection is reachable, the hop-by-hop path, and the average latency. If connectivity fails, the output shows which hop failed and why (NSG block, route problem, or unreachable endpoint).
NSG flow logs in Log Analytics
NSG flow logs record every TCP and UDP flow that traverses an NSG — allowed and denied. Flow logs go to a storage account, and Traffic Analytics processes them into Log Analytics for querying.
# Enable flow logs for an NSG (requires storage account)
az network watcher flow-log create \
--location eastus \
--name flowlog-nsg-snet-web \
--nsg nsg-snet-web \
--resource-group rg-networking \
--storage-account sa-flowlogs-prod \
--enabled true \
--format JSON \
--log-version 2Once flow logs are in Log Analytics (via Traffic Analytics or direct configuration), query for denied flows:
# In Log Analytics (Kusto Query Language)
# Find denied flows from a specific source IP in the last hour
AzureNetworkAnalytics_CL
| where TimeGenerated > ago(1h)
| where FlowStatus_s == "D"
| where SrcIP_s == "10.0.2.10"
| project TimeGenerated, SrcIP_s, DestIP_s, DestPort_d, FlowStatus_s, NSGRule_s
| order by TimeGenerated descCommon problems and their diagnostics
VM cannot reach on-premises after VPN is connected. Run next hop from the VM to an on-premises IP. If the next hop is Internet instead of VirtualNetworkGateway, the spoke VNet is missing gateway transit peering or the route table is overriding the VPN-advertised route. Check that useRemoteGateways is enabled on the spoke peering and that no UDR has a more specific route for the on-premises range.
Private endpoint not working — application gets a timeout or certificate error. Run nslookup from the VM for the service hostname. If nslookup returns a public IP, DNS is the problem — the private DNS zone is missing, the VNet link is missing, or the A record points to the wrong IP. If nslookup returns the correct private IP, run IP flow verify to check if an NSG is blocking the port on the subnet containing the private endpoint.
Outbound internet access blocked after adding Azure Firewall. Check that the Azure Firewall has an application or network rule allowing the required FQDNs or IP ranges. Check the firewall logs in Log Analytics for denied flows from the VM’s IP. Also verify the UDR on the spoke subnet has the 0.0.0.0/0 route pointing to the firewall’s private IP, not to Internet.
DNS not resolving private hostnames. On the VM, run nslookup hostname.internal.mycompany.com 168.63.129.16 to query Azure-provided DNS directly. If this fails but the same query against a public resolver succeeds, the Private DNS zone VNet link is missing or the zone name does not match. If you are using a custom DNS server, verify it is forwarding unknown queries to 168.63.129.16.
Common mistakes
- Testing with IP flow verify but forgetting the NIC-level NSG. IP flow verify tests the effective rules across both the subnet NSG and the NIC NSG. If IP flow verify shows Allow but the connection still fails, confirm that no NIC-level NSG is applying additional rules that override the subnet result. Run effective security rules on the NIC to see both NSG layers together.
- Overlooking NSG rule direction when writing rules. NSG rules are directional — an inbound rule only affects incoming traffic to a resource, and an outbound rule only affects outgoing traffic from it. A common mistake is writing an inbound Allow rule to permit traffic in, but forgetting that return traffic (the response) requires an outbound Allow rule or that NSGs are stateful (they are — for TCP, the return traffic for an allowed inbound flow is automatically allowed outbound).
- Not enabling NSG flow logs before an incident. When a connectivity problem happens in production, the first question is: what traffic was blocked and when? Without flow logs, there is no record. Enable flow logs on all NSGs in production environments proactively, not after a problem occurs. Storage costs for flow log data are low relative to the diagnostic value.
Summary
- IP flow verify tests whether a specific flow is allowed or denied by NSG rules and identifies the exact rule responsible.
- Effective security rules shows all NSG rules (subnet + NIC combined) applied to a VM’s network interface in evaluation order.
- Next hop identifies where Azure will route a packet — use it to verify VPN gateway routing, Azure Firewall path, and detect missing routes (None next hop means dropped traffic).
- Connection troubleshoot tests end-to-end TCP/UDP connectivity including hop-by-hop path and latency.
- Enable NSG flow logs on all production NSGs proactively. Query denied flows in Log Analytics to diagnose blocked traffic.
Frequently asked questions
What is Azure Network Watcher and does it cost anything to enable?
Azure Network Watcher is a collection of network diagnostic and monitoring tools in Azure. Enabling the Network Watcher service itself is free. Some tools (packet capture, connection monitor, flow logs) have storage and data processing costs. Network Watcher is automatically enabled in each region where you have a VNet, but you may need to register the Microsoft.Network resource provider if it is not already registered.
What is the difference between IP flow verify and effective security rules?
IP flow verify tests whether a specific traffic flow (source IP, destination IP, port, protocol, direction) would be allowed or denied by the NSG rules on a VM's NIC. It tells you the yes/no answer for one specific flow and which rule produced that answer. Effective security rules shows you all the NSG rules currently applied to a NIC — both from the subnet NSG and the NIC NSG — in their evaluated order. Use IP flow verify when you know the specific flow that is broken; use effective security rules when you want to audit the complete rule set.
A VM cannot reach a private endpoint. Where do I start?
Start with DNS. Run nslookup from the VM for the service hostname and check if it returns the private IP (10.x.x.x) or the public IP. If it returns the public IP, the Private DNS zone is missing, the VNet link is missing, or the A record is missing. If DNS returns the correct private IP, run IP flow verify to check if an NSG is blocking the traffic on the required port. Then check effective routes on the VM NIC to verify no route is sending traffic to an unexpected next hop.