VNET Peering – When to use and when not to use

VNET Peering has been an available feature for almost a year now and has proved to be a very useful, popular, and for a long time the most requested feature. That said, as much as we would like to mesh together all our Azure VNETs into one lovely firewalled network topology, this isn’t always possible or suitable.

The situations whereby VNET peering (or it’s associated features) cannot be used are as follows:

  • VNETs in different regions cannot have a peering relationship
  • VNETs with overlapping address spaces cannot be peered
  • VNETs which are both created using the Classic Deployment model cannot be peered
  • VNETs which are created using mixed deployment models cannot be peered across different subscriptions (although this will be available in the future)
  • Both VNETs must be created using the Resource Manager Deployment Model for Gateway Chaining (using a gateway in a peered VNET) to function
  • There is a default limit of 10 VNET peers per VNET. This can be raised to a maximum of 50 using Azure Support requests

This still leaves many applicable situations whereby VNET peering can be very useful and can provide the hub and spoke, high speed, low latency network which your Azure subscription/s need.


Set-AzureNetworkSecurityGrouptoSubnet – The virtual network name is not valid.

Another catchy title which I’m sure you’ll be saying to yourself all day.

I came across a problem recently whilst attempting to attach an Azure Network Security Group to a subnet within a virtual network. The purpose of this NSG was in reference to an ADFS configuration in Azure. The NSG was to be used to wrap around our ‘LAN’ subnet in Azure and protect it from the ADFS Proxy servers and the internet by locking down inbound traffic to only allowed ports.

I created my NSG by using:

New-AzureNetworkSecurityGroup -Name "LAN_NSG" -Location "West Europe"

And then attempted to map it to my LAN subnet by using:

Get-AzureNetworkSecurityGroup -Name "LAN_NSG" | Set-AzureNetworkSecurityGroupToSubnet -VirtualNetworkName 192.168.x.x -SubnetName ‘LAN’

However I got a wall of red, with the descriptive error message of:

The virtual network name 192.168.x.x is not valid

NSG - The Virtual Network name is not valid

I then tried specifying the virtual network name in a combination of formats, and also by using a variable:


And so on and so forth, all with the same result. I could however, run:

Get-AzureVNetSite -VNetName 192.168.x.x

Which returned a valid result, confirming my thinking that the VNet name was valid and correct. Eventually I logged a call with Azure Support to try and find out what was going on. I received a prompt response, and was told by the engineer dealing with the call that the problem could be reproduced, and was consistent when trying to apply NSG to a VNet name that starts with a number.

At the moment I’m waiting to hear back to see whether this is a known issue and if there is a prettier workaround other than creating a new VNet and migrating my VMs over to it. Another workaround is to apply the NSG to the VMs themselves, which may be the route that we travel until this issue is solved.