The truth about NSGs

When you apply NSGs to subnets and network interfaces, you might experience some things that you didn’t expected. I cover them in this post.

by | Mar 11, 2018 | General, Security


Dealing with network security has always been important. Even when you are running VMs in Azure, network security is important. A feature of the virtual network stack in Azure that could help you with your line of defence are the Network Security Groups (NSG).  There are a lot of misconceptions regarding NSGs. In this blogpost I will give some clarity on those misconceptions.

Traditional Firewall

When we are talking today about a firewall, most of the time we mean a Next Generation Firewall (NGFW). Next Generation Firewalls contain features such as:

  • Deep Package Inspection
  • Web Application Firewall
  • Reverse Proxy
  • Access Control Lists (ACL)

The earlier firewalls (traditional firewalls) only contained the access control list feature. This is actually what a NSG is; a access control list. You can filter the traffic based on addresses and ports. You define the ports, addresses and filter actions (allow/deny) in a rule. The port and target address of a TCP package can be found in its header. Based on the rules that are configured and the data in the header of the TCP package, the package is dropped or allowed.

Lots of people (and even Microsoft) are calling a NSG a firewall, this cause a lot of stir since the NSG does not provide the feature-set of a NGFW. A NSG is comparable with a traditional firewall… So the term firewall for a NSG isn’t that wrong as most people think, although it’s better to explain a NSG as a ACL.


The network security group does not have the features of a next generation firewall. Although the NSG doesn’t provide these features, it is possible to run a NGFW in Azure. You could deploy a network virtual appliance (NVA) that has NGFW features. More information on network virtual appliances is provided here.

Working flow

In a NSG rules are defined, based on those rules traffic is allowed or dropped. A NSG can contain inbound rules and outbound rules. Most of the time we see the incoming rules and outgoing rules as a separate thing. The rules are actually processed with the same procedure. Check the flow diagram below: (source Microsoft).


Default Rules

NSGs are a great feature in Azure to secure your network environment. By default NSGs are maybe not secure as that you want your environment to be:

  • NSGs are getting deployed with two rules that allow all traffic within the same VNET. AllowVnetInBound allows all incomming traffic if the source is from within the VNET. AllowVnetOutBound allows all outbound traffic where the target address is within the same VNet as where the network interface is deployed.
  • By default all traffic to from network interfaces to the internet is allowd. All your VMs will have internet access.

Defining a rule “deny any/any” might get you in trouble. With such a rule, you also deny traffic to various Azure sercvices (Azure Backup, Operations Management Suite etc.). Be careful with blocking outbound internet traffic for that. You can use service tags to allow traffic from various Azure Services. (Storage, SQL). Azure Backup is within the Azure Storage service tag.

NSG on a subnet

Another interesting thing to mention in this post is how Azure works with NSGs on subnet level. You might expect that enabling a NSG that is applied on a subnet will filter traffic that is coming in or going out of the subnet. This is not true. All NSGs are applied on network interface level.

All rules that you define in a NSG that is assigned to a subnet, will be applied to all network interfaces that reside within that subnet. So blocking a certain protocol/address on subnet level, actually means that all network interfaces in the subnet will block that address/port. This can be inconvenient. Especially if you want to apply rules on a scope (e.g. only allow port 80 to a subnet, and block all other traffic but allow inter-subnet traffic for al resources in the subnet). This is still possible; configuring a rule in your NSG that allows inter-subnet traffic will help you with that.


NSGs are great resources that help is in our line of defense. They are heavily integrated in the Azure platform and quite easy to use. In order to have them working properly, you need to know that:

  • There are some default rules that allow a lot of traffic.You might want to overrule the default rules in order to block more traffic.
  • NSGs on subnets are applied on network interface level. There is no scope of a subnet and network interface.
  • NSGs are often called firewalls, this is a reference to a “traditional firewall.” NGFW features such as deep package inspection are not part of a NSG.
Share This