When working with customers on Microsoft Azure projects, it’s important to address security. Network access control is as important in the cloud as it is on-premise and for this we use Network Security Groups (NSGs).

The purpose of a Network Security Group is to restrict or enable access on the Azure network. You can create a policy and associate it with a virtual machine (VM) or a subnet. Any rules created within that are then applied to the associated resources.

By default, a single NSG in Azure can hold up to 200 rules (combined for inbound and outbound). However, this can be increased upon request to 400  ASM (Azure Service Manager or ‘classic’) or 500 ARM (Azure Resource Manager). The current limits are listed on the Microsoft Azure website.

However our experience of NSGs tells us that there are a few things you need to be wary of.

Firstly, if your NSG does not allow VMs unfiltered outbound Internet access (which they do by default, so you’d have to intentionally disallow it), then you will immediately have an issue to address. That is, to work properly, VMs should have access to all the IP addresses used by Azure in the region in which the VM is running.

This TechNet article explains it in more detail while, for reference, the latest Azure IP ranges for all regions can be downloaded from here.

At this point in time, there are in excess of 200 IP ranges for the North Europe region alone, so if you have to add all those to an NSG, you’re already looking at more rules than are allowed by default (200).

“No problem,” you might think, “I’ll just ask Microsoft to increase it to 500 for my ARM deployment.” That is entirely possible and, in our experience, pretty straightforward. Doing that would leave you just under 300 rules for your own use. That may or may not be enough, but let’s assume that it is for the purposes of the next point. Let’s also assume that you’ve got the increase to 500.

So my next point is regarding the use of large NSGs. Specifically, I strongly recommend that you put each one in its own Resource Group. This is because I have discovered that Azure counts NSG rules towards the limit of 800 resources per Resource Group as opposed to just the actual NSGs themselves. I haven’t found this documented anywhere but I have been unable to add rules to an NSG when that NSG was in the same Resource Group as another NSG and the addition I was attempting to make would have taken the combined number of rules suspiciously close to that magic number of 800 (the NSGs themselves were probably also counting!). When trying this the PowerShell command to add the rule would simply timeout. If I deleted a rule I didn’t need and then tried again, it would add it without any problem so it was definitely not dodgy PS syntax.

Of course, none of this deals with the matter of whether or not you should use or actually need such large NSGs. That will depend on your particular circumstances but a couple of alternative options could be:

  • Use a firewall appliance from the Azure marketplace instead
  • Remove the Azure Region IPs from the NSGs and allow the VMs access to the same destinations using a Proxy Server VM

There is an awful lot more to NSGs than this, of course, but these are just a couple of observations ‘from the field.’

By Chris Sommers, Senior Consultant, SystemsUp

To find out more about how SystemsUp can help you architect the best cloud solution for your requirements please click here.

Related Post