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

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

'192.168.x.x'

"192.168.x.x"

$vnetname=192.168.x.x

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.