Debugging VNet Connectivity Problems in Azure

The diagnostic decision tree

Start with the most specific question and work outward:

1. Does the TCP connection reach the destination at all? If the connection times out, suspect NSG or routing. If you get a TLS error or HTTP error, the network path works.
2. Is an NSG blocking the traffic? Use IP Flow Verify to answer this definitively.
3. Is the traffic being routed to the right place? Use effective routes on the source NIC.
4. Is DNS returning the expected IP? Run nslookup from inside the VM.
5. Does the destination accept the connection? Use Connection Troubleshoot for end-to-end TCP testing.

This order matters. Many engineers jump to checking NSG rules manually without using IP Flow Verify first, wasting time reading through rules that may not even apply to the traffic path.

Before running any Network Watcher commands, ensure the Network Watcher instance exists in the relevant region:

az network watcher list --output table

# If no watcher exists in eastus:
az network watcher configure \
  --resource-group NetworkWatcherRG \
  --locations eastus \
  --enabled true

Step 1: IP Flow Verify — is an NSG blocking traffic?

IP Flow Verify tests whether a specific 5-tuple (protocol, source IP/port, destination IP/port) would be allowed or denied by NSGs applied to a VM’s NIC.

# Get the VM resource ID
VM_ID=$(az vm show \
  --resource-group myResourceGroup \
  --name myVM \
  --query id -o tsv)

# Test outbound HTTP from VM to a specific IP
az network watcher test-ip-flow \
  --vm "$VM_ID" \
  --direction Outbound \
  --protocol TCP \
  --local-ip 10.1.0.4 \
  --local-port 12345 \
  --remote-ip 10.2.0.5 \
  --remote-port 443 \
  --output json

A successful response looks like:

{
  "access": "Allow",
  "ruleName": "AllowVnetInBound",
  "location": "eastus"
}

A blocked flow looks like:

{
  "access": "Deny",
  "ruleName": "DenyInternetOutBound",
  "location": "eastus"
}

The ruleName field tells you exactly which NSG rule is responsible. Look up that rule to understand the priority and modify it:

# Find and list the specific NSG rule
az network nsg rule show \
  --resource-group myResourceGroup \
  --nsg-name myNSG \
  --name DenyInternetOutBound \
  --output json

Step 2: Effective routes — is traffic routing correctly?

If IP Flow Verify shows traffic is allowed but connectivity still fails, the problem may be routing. Check the effective routes on the VM’s NIC to see where traffic is actually being sent:

# Get NIC name for the VM
NIC_NAME=$(az vm show \
  --resource-group myResourceGroup \
  --name myVM \
  --query "networkProfile.networkInterfaces[0].id" -o tsv \
  | xargs -I{} az network nic show --ids {} --query name -o tsv)

# View effective routes on the NIC
az network nic show-effective-route-table \
  --resource-group myResourceGroup \
  --name "$NIC_NAME" \
  --output table

Sample output:

Source    State    Address Prefix    Next Hop Type          Next Hop IP
--------  -------  ----------------  ---------------------  -----------
Default   Active   10.1.0.0/16      VnetLocal
Default   Active   0.0.0.0/0        Internet
User      Active   10.2.0.0/16      VirtualAppliance       10.1.1.4
User      Active   0.0.0.0/0        VirtualAppliance       10.1.1.4

In this example, a user-defined route sends 0.0.0.0/0 to a network virtual appliance at 10.1.1.4. If that appliance is not running or not configured for internet egress, all outbound traffic fails.

Key things to look for:

• “Active” vs “Invalid”: An “Invalid” state means the route has a problem, such as the next hop address being unreachable.
• Multiple routes for the same prefix: The most specific prefix wins. If two routes match, the one with a longer prefix (e.g., /24 beats /16) wins.
• User routes shadowing system routes: A user route for 0.0.0.0/0 overrides the system internet route, which is a common cause of lost internet connectivity.

Step 3: Connection Troubleshoot — end-to-end TCP test

Connection Troubleshoot performs an actual TCP connectivity test from a VM to a destination and shows every hop, including NSG evaluation and routing decisions:

az network watcher test-connectivity \
  --source-resource "$VM_ID" \
  --dest-address 10.2.0.5 \
  --dest-port 443 \
  --output json

The response includes:

{
  "avgLatencyInMs": 3,
  "connectionStatus": "Reachable",
  "hops": [...],
  "maxLatencyInMs": 5,
  "minLatencyInMs": 2,
  "probesFailed": 0,
  "probesSent": 100
}

If connectionStatus is “Unreachable”, the hops array shows where the connection failed and why.

VPN connectivity: BGP and local network gateway issues

When traffic should flow through a VPN Gateway but does not, check the BGP peer status and learned routes:

# Check VPN gateway BGP peer status
az network vnet-gateway list-bgp-peer-status \
  --resource-group myResourceGroup \
  --name myVPNGateway \
  --output table

# Check routes learned via BGP
az network vnet-gateway list-learned-routes \
  --resource-group myResourceGroup \
  --name myVPNGateway \
  --output table

# Check routes advertised to the BGP peer
az network vnet-gateway list-advertised-routes \
  --resource-group myResourceGroup \
  --name myVPNGateway \
  --peer 192.168.1.1 \
  --output table

If the BGP peer shows “Unknown” or the tunnel is not connected, check the local network gateway’s address prefix configuration:

az network local-gateway show \
  --resource-group myResourceGroup \
  --name myLocalGateway \
  --query "{localNetworkAddressSpace: localNetworkAddressSpace, gatewayIpAddress: gatewayIpAddress}" \
  --output json

Common VPN failures:

• Local network gateway address prefix does not match the on-premises network range
• Pre-shared key mismatch between Azure and on-premises device
• BGP AS numbers conflict (Azure uses 65515 by default)
• IKE policy mismatch (algorithms, DH group, lifetime)

Private endpoint connectivity: DNS is the first suspect

When a service with a private endpoint is unreachable from a VM in the VNet, test DNS resolution first. The VM must resolve the service hostname to the private IP, not the public IP.

SSH into the VM and test:

# Should return private IP (10.x.x.x), not public IP
nslookup myaccount.blob.core.windows.net

# Verbose DNS trace to see which server is answering
nslookup -debug myaccount.blob.core.windows.net

# Test TCP connectivity to the resolved IP
curl -v https://myaccount.blob.core.windows.net/mycontainer/myblob

If nslookup returns the public IP, the private DNS zone is either missing, not linked to this VNet, or the VM’s DNS server is not forwarding to Azure DNS (168.63.129.16).

Check private DNS zone links from the CLI:

az network private-dns link vnet list \
  --resource-group myResourceGroup \
  --zone-name privatelink.blob.core.windows.net \
  --output table