Hub-Spoke Peering Traffic Dropped by NSG
Adventure Works has a hub VNet 10.40.0.0/16 and two spoke VNets 10.41.0.0/16 and 10.42.0.0/16, both peered to the hub but not to each other. A VM in spoke1 (10.41.1.4) cannot reach a VM in spoke2 (10.42.1.4) on TCP 443. The hub has an Azure Firewall in 10.40.1.0/24 with a policy allowing the two spoke ranges. Spoke subnets have UDRs sending 0.0.0.0/0 to the firewall's private IP. NSGs on both spoke subnets allow 10.40.0.0/16 inbound and outbound but do not include the other spoke range. A test from spoke1 to the firewall private IP succeeds.
1. Explain why spoke-to-spoke traffic fails and what changes fix it.
Read the worked answer
VNets peered to a hub are not transitively peered. Spoke1 has no route to 10.42.0.0/16 unless one is created, and spoke2 has no route back to 10.41.0.0/16. The UDR sends default traffic to the firewall, which is correct, but two things must hold:
- Routing: spoke1's UDR must send 10.42.0.0/16 (or 0.0.0.0/0) to the firewall, and spoke2 must have a return route to 10.41.0.0/16 via the firewall. If only a default route exists, the firewall must have IP forwarding enabled and the packets must be routable back.
- NSG evaluation: NSGs evaluate traffic by source and destination. The spoke NSGs allow only 10.40.0.0/16, so packets sourced from 10.41.1.4 arriving at 10.42.1.4 are denied by the spoke2 NSG inbound rule. Add rules permitting the peer spoke ranges in both directions, or use service tags/application security groups.
The successful test to the firewall private IP only proves spoke1 can reach the firewall; it does not prove the firewall can forward to spoke2 or that spoke2 accepts the source range.
2. How would you verify each layer without changing production configuration?
Read the worked answer
Use read-only diagnostics:
- Effective routes on both VM NICs to confirm 10.42.0.0/16 and 10.41.0.0/16 appear and point to the firewall or a virtual network gateway.
- Effective security rules on both NICs and subnets to confirm the peer ranges are allowed and no deny rule with higher priority exists.
- Network Watcher IP flow verify from spoke1 to 10.42.1.4:443 to see whether the NSG allows or denies and which rule matched.
- Connection troubleshoot to identify the failing hop.
- Firewall logs to confirm the policy allows the flow and that IP forwarding is active.
Each tool answers a different question; a single tool cannot distinguish routing from NSG denial.