Subnet-scoped peering causes silent packet drops for specific VMs

Question

Environment

• Two VNets: vnet-02 and vnet-03, connected via VNet peering
  • vnet-02: Single subnet (vnet-02_snet) spanning the entire address space
  • vnet-03: Two subnets:
    • vnet-03_snet_1: Untrusted side, used for Internet-facing traffic
    • vnet-03_snet_2: Trusted side, peered to vnet-02_snet
• An NVA in vnet-03 with two NICs: untrusted NIC on vnet-03_snet_1, trusted NIC on vnet-03_snet_2
• Traffic from vnet-03 to vnet-02 originates from the NVA's trusted NIC on vnet-03_snet_2 (confirmed correct egress interface)
• No VPN Gateway, ExpressRoute or additional UDRs (default route to NVA not yet created)
• Accelerated Networking disabled on all VMs
• All VM NICs have unique IPs within their correct subnets

Issue Description

After an initially fully functional subnet vnet peering, partial connectivity failure developed over a period of days without any configuration changes being made. From the NVA in vnet-03 (via its trusted NIC on vnet-03_snet_2), only 3 out of 6 hosts in vnet-02 are reachable. The 3 affected hosts are completely unreachable from the NVA, while reverse traffic, from all 6 hosts in vnet-02 back to the NVA, works without issue in all cases.

The failure pattern appears to be zone-related. The affected VMs are pinned to specific Availability Zones (Zone 1 and Zone 2), while reachable VMs are either in Zone 3 or not zone-pinned. Notably, a not-zoned-pinned affected VM where deallocated and restarted, after which connectivity were restored. Another VM also deallocated and restarted, are still unreachable.

The peering is configured as subnet-scoped peering (vnet-03_snet_2 to vnet-02_snet) rather than full vnet-to-vnet peering. Replacing the subnet-scoped peering with a full vnet-to-vnet peering resolved the issue entirely.

Troubleshooting Steps Performed

1. Packet flow logs: Confirmed traffic is marked as allowed and transmitted from vnet-03_snet_2. No trace of those packets are found anywhere in vnet-02, indicating a silent drop in the Azure networking fabric between the two vnets.
2. Next Hop diagnostic tool: Confirmed next hop for affected destinations resolved to VirtualNetworkPeering on both sides. Routing was correct.
3. NSG verification: Manually reviewed and verified using Azure diagnostics tools. All relevant rules allows the traffic in both directions. The NVA's trusted NIC and the destination NICs in vnet-02 are both confirmed as not subject to any blocking rules.
4. Peering state: Verified as Connected and in sync on both sides. The sync button is greyed out, indicating no sync is needed. Peering has been fully removed and re-added, issue persisted.
5. Address space and subnet review: Confirmed no address space overlap, no recently added ranges, and correct subnet usage on both sides.
6. tcpdump on affected VMs in vnet-02: Confirmed that packets never arrived at the OS level on the affected VMs during active send attempts from the NVA. Drops are occurring below the guest OS, within the Azure fabric.
7. VM deallocation and reallocation: Deallocating and reallocating a non-zone-pinned affected VM resolved connectivity for that VM, suggesting the issue is tied to the specific host node it was placed on. Two remaining affected VMs are zone-pinned (Zone 1 and Zone 3); repeated deallocation and reallocation of one of the zoned VMs did not resolve the issue.
8. Peering scope change: Replacing the subnet-scoped peering with a full vnet-to-vnet peering immediately restores full connectivity to all affected VMs without any other changes.

Answer 1

Hi @ Lucas Hökerberg,

Welcome to Microsoft Q&A Platform.

It looks like you’ve run into a known limitation in Azure’s subnet-scoped peering (a.k.a. “subnet peering”) when used with certain VM SKUs and Availability Zones. Here’s the short of it:

• Subnet peering is still relatively new and has a hard dependency on the underlying host hardware. VMs pinned to older-generation hosts (or non-V5 SKUs) in some zones can see packets dropped in the Azure fabric below the guest OS—exactly the silent drops you described.
• When you deallocated a non-zoned VM (it landed on newer hardware), peering “just worked” again. When you replaced with full VNet-to-VNet peering, you bypassed the newer subnet-peering path altogether, so connectivity returned immediately.

Why full VNet peering works

• VNet-to-VNet peering uses a mature, well-tested fabric path that doesn’t have this SKU-and-zone dependency.

How to fix

• Short-term: keep using full VNet peering between vnet-02 and vnet-03.
• Medium-term: migrate the affected VMs to Intel-based V5 SKUs (or AMD Genoa/Cobalt-100 SKUs) and reprovision them so they land on supported host hardware. Once they’re on V5 hardware, subnet peering will work reliably in all zones.

Ref:

How to configure subnet peering (see “Hard limitation”)
Azure virtual network peering overview

Troubleshoot virtual network peering problems 

Pleaseand “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Answer 2

Lucas Hökerberg hey hey )))

yeah this one is actually a really good catch, and tbh this doesnt look like misconfig at all, it looks like Azure fabric bug / limitation with subnet-scoped peering.

ur data already proves it pretty clean routing correct, NSG clean, packets leave NVA but never arrive, reverse path works, and switching to full VNet peering fixes everything > that rules out 99 percent of normal causes

key signals silent drop in fabric (no trace in vnet-02) + zone correlation + partial impact (3/6 VMs) + realloc fixes one VM > host placement sensitive.

that combination almost always points to underlay issue (host/zone mapping or SDN path), not control plane config

subnet-scoped peering is newer and less battle-tested vs full VNet peering, and what ur seeing looks like incorrect mapping of subnet scope to backend host routes across zones, so some compute hosts never get correct forwarding entry > packets dropped before reaching NIC.

important detail reverse works > return path is fine > issue is forward path programming in fabric, not symmetric routing

the fact that deallocate/reallocate fixed one VM is huge signal u moved VM to different host path works confirms host-level mapping issue.

this is support case, not something u can fix, open ticket and include exact timestamps + affected VM IPs + zones + note that full VNet peering resolves issue immediately + mention subnet-scoped peering + zone-specific drops + no NSG + no UDR. this is gold for networking team, they can trace fabric path....

dont use subnet-scoped peering here for now stick with full VNet peering until this is fixed.

so my thinks it is not ur config, its Azure fabric issue with subnet-scoped peering across zones, proven by host relocation + full peering fix.rgds,

Alex

&pls if it helps accept my answer and mark it as an answer