Microsoft 365


Active Directory


Windows Server


Chance to win $250 in Petri 2023 Audience Survey


Microsoft Azure

Configuring Network Security Groups in Microsoft Azure

Russell Smith


In this Ask the Admin, I’ll show you how to secure Microsoft Azure virtual networks using Network Security Groups.

You might already be familiar with another type of network security in Azure that’s used to control access to individual virtual machines (VMs) from the public Internet. By default Azure VMs receive two endpoints when they are provisioned to allow RDP access and PowerShell remoting.

Introduced in autumn 2014, Azure Network Security Groups (NSGs) are high-level objects in your Azure subscription that are created in an Azure region. They differ from endpoint-based ACLs in that they can be applied to more than one VM by associating them with VMs or subnets. They can also survive the lifecycle of VMs and are typically used to fence off Azure subnets from one another without needing to specify endpoint-based network ACLs for each VM in the subnet.

For example, you might want to create a DMZ, and then restrict network traffic that flows between additional subnets: one designated for application servers, and the other for database servers. NSGs control all inbound and outbound access to and from associated VMs, but not from the public Internet.

Network Security Group Prerequisites

There are a couple of prerequisites that you’ll need to consider in advance of deploying NSGs. Before a NSG can be associated with a VM, all endpoint-based network ACLs must be removed. NSGs override endpoint-based network ACLs, so they don’t need to be explicitly removed if you plan to associate a NSG with a subnet. Secondly, NSGs can only be used with VMs in regional VNets, i.e. not those associated with an affinity group.

NSGs are managed using PowerShell, so you’ll need to set up the latest Microsoft Azure PowerShell tools on your PC and make a connection to an Azure subscription as shown in Setup Windows Azure PowerShell Management on the Petri IT Knowledgebase. If you haven’t already done so, make sure you set your Azure subscription and storage account in PowerShell using the Set-AzureSubscription cmdlet.

Creating a Network Security Group

In my Azure lab, I have two subnets in my VNet. Subnet-1 is the Internet-facing frontend with access controlled to a single VM using the default endpoint-based network ACLs, and Subnet-2 will be secured with a NSG to ensure that only specific network traffic is allowed to pass inbound from Subnet-1.

On your management PC, open a PowerShell prompt and enter the command below. You’ll need to specify the region where your VNet is located, for instance ‘north europe’ as shown, or ‘uswest’ for example.

Now that we have a NSG, let's look at the list of default rules.
The default rules in a Network Security Group. (Image Credit: Russell Smith)

The default rules in a Network Security Group. (Image Credit: Russell Smith)

Notice in the output that there a three inbound and three outbound rules. Rules are assigned a priority, and while the default rules cannot be deleted, they can be overridden by rules with higher priority. I.e., a rule with a priority of 100 will override a rule with a priority of 200. Three default tags can be used in rules. VIRTUAL_NETWORK is used as a cache all for IP addresses on the local Vnet, AZURE_LOADBALANCER translates to IP addresses in the Azure infrastructure for probing VM health, and INTERNET specifies inter-Azure traffic, between Vnets that are connected by VPN for example, and not the public Internet. The default rules allow all inbound and outbound traffic between VMs on the same VNet, permit outbound INTERNET traffic, and accommodate Azure VM health probes. All other inbound and outbound traffic is blocked. Now I need to associate the NSG with my backend subnet (Subnet-2):
Because NSGs override endpoint-based network ACLs, the only way to connect to the VM in Subnet-2 using RDP over the public Internet is to bounce off a VM located in my frontend subnet, and because the default NSG rules allow all inbound connections from VMs located in the same VNet, I'm able to do this now that the NSG has been associated with Subnet-2.

Let's lock down Subnet-2 so that VMs in Subnet-1 are only able to make a connection on RDP port 3389, and all other network traffic will be blocked. First, I need to add a rule to the NSG that blocks all traffic, and secondly a second rule with higher priority that allows only RDP to pass from Subnet-1 ( to Subnet-2 (
If you test an RDP connection from a VM in Subnet-1 to a VM in Subnet-2, it will be blocked. Now let's open RDP inbound to Subnet-2 from Subnet-1. The lowest value possible for -Priority is 100, meaning that you can't override a rule with a priority of 100.
New inbound rules in a Network Security Group only allow inbound RDP access. (Image Credit: Russell Smith)

New inbound rules in a Network Security Group only allow inbound RDP access. (Image Credit: Russell Smith)

Now you will be able to make an RDP connection from Subnet-1 to Subnet-2, but all other network traffic is blocked. To remove a rule from a NSG:
It's also possible to associate a NSG with a VM instead of a subnet, replacing the values for –ServiceName and –Name as appropriate:

Finally to delete a NSG, disassociate it from the subnet or VM, and then remove it from Azure:

Article saved!

Access saved content from your profile page. View Saved