I'm designing an Azure hub-and-spoke network with several spoke VNets connected through a hub VNet. The hub contains VMs that act as network virtual appliances (NVAs), and user-defined routes send selected spoke traffic through those appliances. I'm planning to add another VNet, but standard VNet peering makes the full address spaces reachable at the virtual network level.
I want the new VNet to communicate only with specific IP prefixes that are intentionally routed through the NVA, while blocking direct access to all other ranges in the peered VNets. The NVA already has a firewall, but that only controls traffic that actually passes through it and may not prevent other traffic within the peered network from bypassing it.
I've considered subnet peering, but its current limitation of allowing a subnet to participate in only one subnet-peering relationship may not fit this design. VPN Gateway connections also don't appear to provide an easy way to advertise or enforce access to only selected prefixes.
What architecture or Azure features would you recommend for implementing this kind of selective connectivity?
4 Answers
If the VNets are already fully peered, use NSGs to deny traffic by default and add allow rules only for the required prefixes. The UDRs can continue sending intended traffic to the NVA, while the NSGs block unwanted access.
The drawback is operational complexity: applying identical rules across every subnet can be restrictive, while managing separate NSGs for many subnets creates additional infrastructure overhead.
Subnet peering may be the closest fit here. Instead of peering the entire VNets, you could peer only the subnet containing the NVA, depending on how the rest of your routing is designed. Keep in mind that subnet peering is still subject to feature limitations, so verify that the one-peering-per-subnet restriction works for your topology.
If you use Azure Virtual Network Manager, review its security administration rules and default security rules. They may help establish centralized deny and allow policies across network groups, reducing the need to maintain every NSG rule independently. You would still need to validate how those rules interact with your routing and NVA design.
The NVA firewall can enforce the policy for traffic that is routed through it, so make sure the route tables force the desired prefixes through the appliance. However, the firewall alone does not stop direct VNet-to-VNet traffic that bypasses the NVA. You would still need subnet-level controls such as NSGs, or a topology that avoids broad VNet peering in the first place.
That’s my concern with the NSG approach. It would work technically, but applying the same policy everywhere or maintaining a separate NSG per subnet could become difficult to manage as the environment grows.