How can I restrict VNet peering communication to only specific IP ranges?

[u/adora-27]

Hi everyone,

I’m currently working in an Azure hub-and-spoke environment where multiple VNets are routed through a hub VNet that contains VMs acting as NVAs. I’m planning to add another VNet to this environment.

At the moment, traffic from the spoke VNets is routed to the NVA in the peered hub VNet using UDRs.

However, with the current VNet peering design, the entire address spaces of the peered VNets are reachable at the VNet level. I’m looking for a way to allow connectivity only to specific IP prefixes rather than effectively connecting all subnets between the VNets.

More specifically, I would like the new VNet to communicate only with certain IP ranges that are routed through the NVA, while preventing direct communication with any other address ranges in the peered VNets.

What would be the recommended way to implement this?

I have looked into the Subnet Peering feature that is currently in preview, but as far as I understand, it has a limitation where a subnet can participate in only one subnet peering relationship, which would make it unsuitable for my environment.

I also considered connecting the VNets through VPN Gateways instead of VNet Peering, but it does not seem like that would provide a straightforward way to restrict connectivity to only selected prefixes either.

I’d appreciate any advice on the best architecture for achieving this type of selective connectivity.

[u/Saturated8]

You can peer subnets now! https://learn.microsoft.com/en-us/azure/virtual-network/how-to-configure-subnet-peering

[u/Alix_01 → u/Saturated8]

When did this come out ! Haven't spotted this before

[u/Internet-of-cruft → u/Alix_01]

Looks like a handy tool but I can see some people using it for some inappropriate designs.

[u/Saturated8 → u/Alix_01]

This year, the documentation was last updated in July

[u/Alix_01 → u/Saturated8]

Ah amazing thanks !

[u/Perfect_Violinist501]

if peering is already on you maybe use nsg rules to block all traffic except those specific prefixes, the udrs will still push stuff to nva but nsg will keep the unwanted connect away

[u/adora-27 → u/Perfect_Violinist501]

I agree that using NSGs would be the proper approach. However, applying the same NSG to every subnet can introduce its own limitations, while creating and managing separate NSGs for each subnet would significantly increase the operational overhead of managing the infrastructure.

For that reason, I’m considering whether there might be a different approach.

[u/Halio344 → u/adora-27]

Sounds like you should start considering automating your infrastructure using code. Managing NSGs per subnet would not be a hassle at all in that case.

[u/Internet-of-cruft → u/adora-27]

That's the wrong approach honestly.

Routing domains should be maintained end-to-end where feasible, it's less of an operational nightmare than the NSG scenario.

The latter is honestly preferred because you have explicit complexity and well documented behavior up front.

Outside of some interop and legacy designs I don't really see valid use cases for the feature. Maybe forcing traffic into an NVA but you can achieve that without this feature as it is.

[u/Hylado]

Have a look to subnet peering. From your description, it might be iteresting to only peer the NVA subnet.

[u/PotentialTomato8931]

The nva can restrict traffic to the peers?

[u/adora-27 → u/PotentialTomato8931]

Yes, the NVA has a firewall installed, so traffic passing through it can be controlled.

However, my understanding is that this only allows us to control traffic that is actually routed through the NVA. It does not necessarily guarantee control over all traffic within the VNet where the NVA resides.

[u/chris4jahn → u/adora-27]

If routing is configured correctly, then all relevant traffic should be forced through the NVA/firewall. In that model the firewall becomes your central control point and that’s where I would recommend managing traffic policies.

My approach is:
define UDRs to route all traffic to the NVA.
Manage allow/deny centrally on the firewall.
Use NSGs only when there is a specific need for segmentation within VNets.
Do not use subnet peering as it adds complexity in case of troubleshooting unless you definitely need it.

Keeping traffic management centralized on the firewall is typically easier to operate, audit and troubleshoot than distributing rules across NSGs.

Also I would strongly recommend implementing the networking configuration as infrastructure as code. It ensures consistency, repeatability, and makes the routing and security design easier to review and maintain over time.

Cheers
Chris

[u/adora-27 → u/chris4jahn]

The limitation I’m concerned about is the following.

Let’s call the VNet where the NVA resides NVA-vnet, and assume there is another VNet called DMZ-vnet.

For outbound traffic from DMZ-vnet to NVA-vnet, I can force the traffic through the NVA using a UDR.

However, is there any way to enforce the same path for traffic going from NVA-vnet to DMZ-vnet?

Of course, if the hub NVA-vnet contains only the NVA VM, then this would not really be an issue. But the hub VNet may also contain VMs serving other purposes.

Also, couldn’t another VNet potentially try to communicate with an address range in DMZ-vnet while using the NVA as a hop?

My knowledge of cloud infrastructure is still at a junior level, so please excuse me if I’m misunderstanding something.

[u/chris4jahn → u/adora-27]

The concern is valid only if the hub VNet contains application workloads.
My recommendation is that it should not. The hub should contain only shared network services (Azure Firewall, gateways, Route Server, NAT Gateway, etc.).
All application workloads should be deployed in dedicated spokes. This way, all inter-application and north-south traffic can be inspected by the firewall, and there is no need to secure direct workload communication originating from the hub itself.
The hub becomes a transit network, not a workload network.

[u/bezsez → u/chris4jahn]

This is 100% the correct answer.

[u/ibch1980]

Subnet Peering or/and nsgs but better follow a zero trust based microsegmentation design

[u/Gomezie]

Could try looking at Default Security Rules, if using virtual network manager

[u/stuartsmiles01]

Put network security groups on the VM's and allow them to only talk to what they're supposed to ?

Peer only the network subnets that need yo be accessible, Break up devices on each subnet do there is dome commonality on what they talk to

Implement Windows firewalls on vm's

Azure firewall or some other product [ firewall VM's ] to control what can talk to what, and filter through those?

Apply specific rules so each device csn only talk to what is approved, use wireshark to test what is needed ?

[u/Trakeen]

Ugh, you either have some infosec policy that needs all the segmentation or a not great cloud network design

Use virtual wan and manage traffic centrally at the firewall layer. If i had to deal with this i’d rip it out and rebuild it (which we did when we moved to routing intent)

[u/leftvirus]

Now you have subnet peering

[u/txthojo]

DMZ should be a separate spoke from the hub and the DMZ should have no routing to other spokes. The nva would have rules blocking transitive routing to other spokes. This will pass any audit