How to Troubleshoot Azure Virtual Network Issues

Why This Is Happening

I've seen this exact scenario play out hundreds of times in enterprise environments: you spin up a new VM in Azure, assign it to a Virtual Network, and then , nothing. The VM can't reach the internet, can't talk to another VM in the same VNet, or the application that worked perfectly in dev suddenly breaks in production. Your Azure Virtual Network troubleshooting journey starts here, and I want you to know upfront: it's almost never a random Azure glitch. There's always a reason, and it's almost always findable.

Azure Virtual Networks (VNets) are the foundation of your cloud network architecture. They give your resources a private, isolated IP space in the cloud. But that isolation , which is the whole point, also means that connectivity doesn't just "happen." Every packet has to navigate through Network Security Groups (NSGs), route tables, DNS resolution, peering configurations, and sometimes VPN or ExpressRoute gateways before it reaches its destination. Any one of those layers can silently drop traffic with no obvious error message.

Here's what I see causing the majority of Azure VNet connectivity issues in real deployments:

• NSG rules blocking traffic, either an inbound or outbound rule denying traffic that your app depends on. The default "DenyAllInbound" rule at priority 65500 catches everything not explicitly permitted.
• Incorrect or missing User Defined Routes (UDRs), a custom route table attached to a subnet that's sending traffic to a firewall NVA (Network Virtual Appliance) that isn't configured to pass it through.
• VNet Peering misconfiguration, peering connections that are showing "Connected" on both sides but have "Allow forwarded traffic" or "Allow gateway transit" set incorrectly.
• DNS resolution failures, VMs resolving names to wrong IPs because the VNet DNS server setting points to the wrong address, or Private DNS Zones aren't linked to the correct VNet.
• Overlapping address spaces, particularly common when companies expand their Azure footprint and two VNets end up with conflicting CIDR blocks, making peering impossible.
• VPN Gateway or ExpressRoute circuit problems, BGP session drops, authentication failures, or IKEv2 negotiation mismatches cutting off on-premises connectivity.

I know this is frustrating, especially when it blocks your work and you're staring at an error that says absolutely nothing useful. The good news is that Azure gives you surprisingly powerful diagnostic tools, and once you know the right sequence to use them, you can pinpoint most Azure VNet issues in under 15 minutes. Let's get into it.

The Quick Fix, Try This First

Before you go deep into logs and route tables, run Azure Network Watcher's IP Flow Verify tool. This is the single fastest way to determine whether a Network Security Group is the culprit. I've watched engineers spend two hours manually reading NSG rules when this tool gives you the answer in 30 seconds.

Here's how to do it:

1. In the Azure Portal, search for Network Watcher in the top search bar and open it.
2. In the left-hand menu under Network diagnostic tools, click IP flow verify.
3. Fill in the fields:
   • Virtual machine: select the VM that's having connectivity problems
   • Network interface: select its NIC
   • Protocol: TCP or UDP depending on what you're testing
   • Direction: Inbound or Outbound
   • Local IP / Local port: the VM's IP and the port your app listens on
   • Remote IP / Remote port: the source you're testing from and its port
4. Click Check.

The result will tell you either "Access allowed" or "Access denied", and critically, it tells you which specific NSG rule is responsible. If you see "DenyAllInbound" listed, that means no explicit allow rule exists for that traffic and the default deny is catching it. If you see a custom rule name, you know exactly which rule to edit.

If IP Flow Verify shows "Access allowed" but traffic still isn't getting through, that tells you the NSG isn't the problem, which is actually great news because it narrows your search immediately. The issue is then in routing, DNS, the application layer, or the destination endpoint itself. Move on to the step-by-step section to continue the investigation.

Advanced Troubleshooting

Using Network Watcher Packet Capture

When you need to see exactly what's on the wire, Azure Network Watcher packet capture is your answer. This captures traffic at the VM's NIC level and saves it as a .pcap file to a storage account, no need to install Wireshark on the VM itself or deal with OS-level firewall complications. I reach for this when the higher-level tools all say traffic is fine but the application still reports connection failures, which usually points to a TCP handshake issue or TLS negotiation problem.

To start a capture: go to Network Watcher > Packet capture > Add. Set the target VM, storage account destination, optional filters (e.g., only capture traffic on TCP port 443 from a specific remote IP), and a time limit. The capture file can then be downloaded and opened in Wireshark locally for analysis. Look for TCP RST packets (connection refused), SYN packets with no SYN-ACK response (firewall drop), or TLS alert handshake failures.

Event Viewer and Azure Monitor Logs

For Windows VMs, Event Viewer can surface network-related errors that Azure's portal tools miss. Check Windows Logs > System for Event ID 4227 (TCP/IP failed to establish connection) and Event ID 1014 (DNS name resolution timeout). For deeper Azure platform-level diagnostics, enable NSG Flow Logs in Network Watcher, these log every flow through your NSG to a storage account and can be queried through Azure Monitor or Traffic Analytics.

To enable NSG flow logs:

# Via Azure CLI
az network watcher flow-log create \
  --location eastus \
  --name MyFlowLog \
  --nsg YourNSGName \
  --storage-account YourStorageAccountId \
  --enabled true \
  --format JSON \
  --log-version 2

Flow log version 2 includes throughput information (bytes and packets per flow), which helps identify whether a specific flow is being dropped or throttled.

VPN Gateway and ExpressRoute Diagnosis

Azure VPN Gateway connection failed errors are particularly nasty because they can have dozens of root causes. The most common ones I see are IKE authentication mismatches (pre-shared key typo or certificate mismatch), Phase 1/Phase 2 policy misalignment between Azure and the on-premises VPN device, and BGP peering drops on ExpressRoute circuits.

For VPN Gateway, go to the gateway resource in the Portal and click VPN troubleshoot under Monitoring. Point it to a storage account and run the diagnostic, it generates a detailed report showing the IKE negotiation logs and exactly where the handshake failed. For ExpressRoute, check the circuit's BGP Summary under the connection resource, if the BGP peer state shows "Idle" or "Connect" instead of "Established," the session is down and needs to be investigated on both the provider side and the Microsoft edge router side.

Overlapping Address Space Problems

If you're trying to peer two VNets with overlapping CIDR ranges, Azure will simply refuse to create the peering, you'll get error code RemoteVnetAddressSpaceOverlap. The only fix is to re-address one of the VNets, which unfortunately requires deleting and recreating subnets (and migrating VMs out of them first). Plan address spaces carefully at the start using a proper IPAM approach, I can't stress this enough.

Prevention & Best Practices

The best Azure Virtual Network troubleshooting session is the one you never have to do. After working through countless networking incidents in Azure, here's what the teams with the fewest outages consistently do right.

Design your address space before you deploy anything. The CIDR blocks you pick on day one are very difficult to change later. Use a range like 10.0.0.0/8 and carve it up deliberately, different /16 blocks for different environments (dev, staging, prod), different /24 blocks for different application tiers within each environment. Keep a spreadsheet or use an Azure-native IPAM tool to track allocations. Leave room to grow, you'll always need more address space than you expect.

Follow the principle of least privilege with NSG rules. Never open 0.0.0.0/0 on port 22 or 3389 to the internet. Use Azure Bastion for administrative access instead, it's cleaner, more auditable, and eliminates an entire class of attack surface. For internal traffic, use Azure Service Tags (like AzureLoadBalancer or VirtualNetwork) instead of hardcoded IP ranges so your rules stay valid as infrastructure changes.

Enable NSG Flow Logs and Traffic Analytics from the start, not after an incident happens. Having historical flow data when you're investigating "why did this break at 2am" is invaluable. Flow logs cost almost nothing at low traffic volumes and they've saved me hours of guesswork in post-incident reviews.

Tag everything. Every VNet, subnet, NSG, route table, and peering should have consistent tags for environment, application, owner, and cost center. When you're troubleshooting at 11pm and can't remember which NSG belongs to which application tier, good tagging is the difference between a 5-minute investigation and a 2-hour one.

Frequently Asked Questions