You refresh the Azure portal after creating a VNet peering and the status says “Disconnected”. You check the address space overlap but everything looks right. So what might be happening?
By Design, VNet peering is bi-directional in Azure and both the VNets need to be configured independently to work correctly. Let’s say that you create a peering from VNet-A to VNet-B, the peering object exists on VNet-A. VNet-B does not have a corresponding peering back to VNet-A yet. Therefore, Azure won’t establish the connection unless both VNets acknowledge each other.
What does Disconnected mean?
It means that I have a peering pointed outwards, but the other end hasn’t responded. It is NOT a misconfiguration on your side, but an incomplete configuration across both VNets.
To fix this, you need to go to VNet-B and create a matching peering back to VNet-A. This will complete the peering setup. The status will change to “Connected” on both sides and traffic starts flowing.
Sometimes we assume that a Disconnected status means overlapping address spaces. This is a common point of confusion in such scenarios. If the address spaces are overlapping, Azure won’t even let you create the peering in the first place. You will get an explicit error during creation. The status “Disconnected” is a different problem. It just means that one side is missing the peering configuration.
It’s also worth knowing that peering is non-transitive in nature. Eg: You have three different virtual networks named VNet-A, VNet-B, and VNet-C. VNet-A is peered with VNet-B, and VNet-A is peered with VNet-C. Traffic from VNet-B cannot reach VNet-C via VNet-A. Each pair needs its own direct peering to work. The only way to route spoke-to-spoke traffic through a hub is with User-Defined Routes and a Network Virtual Appliance, which is covered later in this guide.
Fig 1. Connected vs Disconnected VNet peering — both sides must be configured independently.
Private DNS Zones Stop Working When You Add a Custom DNS Server
Let’s say you configured a private DNS zone, linked it correctly to the VNet, and enabled auto-registration.
Then someone from your team adds a custom DNS server to the VNet. Suddenly, the private zone resolution stops working entirely and you are wondering what went wrong!
This type of issue happens because of how Azure routes DNS queries. The resolution priority is:
- NIC-level DNS : if set, this is always used, regardless of the VNet settings
- VNet-level DNS : if no NIC-level DNS is configured
- Azure-provided DNS (168.63.129.16) : only used when neither of the above is configured
Private DNS zones are resolved by Azure’s internal resolver at 168.63.129.16. This resolver is what makes private zone lookups work. The moment you configure a custom DNS server at the VNet or NIC level, queries stop going to Azure’s resolver and instead go to your custom server. Your private zone link becomes completely irrelevant for those VMs.
And this is not a bug or an error, it’s by design. Azure assumes that if you have configured a custom DNS server, you wish to have full control over name resolution. The private zone is still there but it is just not in the resolution path anymore.
The standard fix is to run a DNS forwarder that handles internal names itself and forwards everything else to 168.63.129.16. This lets you use a custom DNS server while still reaching private DNS zones. This is often deployed on a VM or using Azure DNS Private Resolver — both of which are covered in the AZ-104 Compute domain guide at CrackCerts. The DNS forwarder is often on a VM or on an Azure DNS Private resolver.
Fig 2. DNS resolution priority in Azure — a custom DNS server at the NIC or VNet level bypasses private DNS zones entirely.
NSG Default Rules Allow More Than You Expect
When you create a new network security group (NSG), it looks empty. However, it’s important to note that every newly created NSG comes with three inbound and three outbound default rules. And, you cannot delete these default rules.
Understanding these rules is quite important, as these define the baseline traffic behaviour before you add any rule of your own.
The inbound defaults:
- AllowVnetInBound (priority 65000) : This rule allows all traffic between resources in the same VNet
- AllowAzureLoadBalancerInBound (priority 65001) : This allows health probes from the Azure Load Balancer
- DenyAllInBound (priority 65500) : It denies everything else
The outbound defaults:
- AllowVnetOutBound (priority 65000) : It allows all outbound traffic to VNet addresses
- AllowInternetOutBound (priority 65001) : This allows all outbound traffic to the internet
- DenyAllOutBound (priority 65500) : It denies everything else
Important point that network engineers often miss:
The AllowVnetInBound rule uses the VirtualNetwork service tag, which actually covers not just the local VNet but also peered VNets and VNets connected via VPN gateway. So if you peer two VNets without modifying the NSG, traffic between them is allowed by default.
Outbound internet traffic is allowed by default. Many engineers assume NSGs are deny-all until you open ports. They’re not. Outbound to the internet flows freely unless you explicitly add a deny rule. If you need to restrict outbound, you need to add rules before the AllowInternetOutBound default.
Note:
When debugging NSG issues, use the Effective Security Rules view in the portal (under the NIC’s NSG blade). It shows you the merged, priority-ordered list of all rules actually in effect. This is much faster than manually tracing which rules apply from which NSG.
Fig 3. NSG default rules — Azure creates these automatically. Note that outbound internet is allowed by default.
Your NVA Is Being Bypassed Because the Route Table Is on the Wrong Subnet
You deploy a Network Virtual Appliance (NVA) for traffic inspection. You have already created a route table with a User-Defined Route that is pointing to the NVA’s private IP. The traffic is flowing, but the NVA never sees it.
Route tables in Azure are associated with subnets, not VNets or NICs. The route table only controls traffic leaving the subnet it is associated with. If you associate the route table with a spoke subnet and expect it to intercept traffic from a VPN gateway, it won’t simply work. The route table needs to be associated with the GatewaySubnet.
Traffic from on-premises arrives at the VPN gateway, which lives in the GatewaySubnet. To force that traffic through the NVA before it reaches any spoke resources, you associate the UDR route table with the GatewaySubnet and NOT with the destination subnet.
For spoke-to-spoke traffic through a hub NVA, you need UDRs on both spoke subnets, pointing to the NVA’s private IP as the next hop, with next hop type set to Virtual Appliance (the only next hop type that requires an explicit IP address).
One more thing. Route tables are regional. A route table created in the East US region cannot be associated with a subnet in the West Europe region. If your VNet spans regions via peering, you need separate route tables in each region.
VPN Gateway Transit Requires Settings on Both Sides
Let’s imagine a Hub-spoke topology. VNet-Hub has a VPN gateway connected to on-premises. VNet-Spoke is peered to VNet-Hub. You want VNet-Spoke resources to reach on-premises through the hub’s gateway without deploying a second gateway. This is gateway transit which is a great cost-saving pattern. But it requires configuration on both sides of the peering, not just on any one side.
On VNet-Hub (the peering from Hub to Spoke): enable “Allow gateway transit“
On VNet-Spoke (the peering from Spoke to Hub): enable “Use remote gateways“
If you miss either one then the transit will not work. The most common mistake is enabling “Allow gateway transit” on the hub side but forgetting to enable “Use remote gateways” on the spoke side.
There is one hard constraint to remember: “Use remote gateways” is only available when VNet-Spoke does not have its own virtual network gateway. If a gateway already exists in the spoke, the option is greyed out. This pattern is for scenarios where the hub owns the connectivity and spokes are purely consumers.
Wrapping Up
These five behaviours, bidirectional peering requirements, DNS resolution priority, NSG default rules, route table scope, and gateway transit configuration, are the ones that come up repeatedly when working with Azure networking at any serious scale. None of them are difficult once understood. It’s just that the why doesn’t always surface at the right moment.
If you want to go deeper on any of these, the AZ-104 Networking domain guide at CrackCerts covers each of these areas with clear-focused context.
