As mentioned in a previous blog – NSG’s control access by permitting or denying network traffic in a number of ways, whether it be:-
- Communication between different workloads on a vNET
- Network connectivity from on-site environment into Azure
- Direct internet connection
1. One NSG to rule them all
Do you really need a NSG per subnet? Or even, per VNET?
For most cases, the answer is no – you can combine one NSG across multiple NICs, Subnets or even vNETs.
NSG do have limitation, the number of rules by default are 200 and with a support ticket raised the maximum rules in a NSG is 1000. Unless you are reaching this maximum, multiple are not needed!
2. How are NSG rules enforced?
A quick thought, do you know the order of how the NSG rules are enforced?
Understanding the effective rules of a NSG(s) is critical. Rules are applied to the network traffic by priority in each NSG in the following order:-
For both inbound and outbound traffic a NSG that is applied to the NIC takes priority over a NSG applied to the subnet!
3. Naming convention
Like all networking rulesets, it may be daft but a proper naming convention from the start will make the support process a lot easier! Have an adequate name for each rule, such as:
“WebServerProduction-to-DatabaseProduction-SQLConnection” and not something along the lines of “Rule35-SQL”
4. Think before you deploy (Group Rules & Ports)
Got the rule set scope? Know the initial rule set you will be applying? Great!
IP ranges should be used rather than a series of sequential IPs, along with ports in a similar format:
IP range: 192.168.1.0/24 rather than 192.168.1.1, 192.168.1.2… etc
Ports: 80-82 rather than 80,81,82… etc
Both these suggestions will mitigate the total amount of NSG rules.
5. NSG Rule Priority
NSG rules are applied in a prioritised order between 100 & 4,096, with each new rule being sequentially added. Rules are analysed on a granular level, each rule is checked in order of priority – once one rule has been found that matches the traffic it will not check the rest of the rules.
For example, if traffic matched rule 110 – traffic will attempt to be sent using this rule. This may be a consideration for when multiple rules may attempt to overlap each other.
6. NSG Tags
Service Tags within NSGs are in theory a network “object” that contain a group of IP addresses to assist with helping to minimise the need for a complex rule list. These tags are Microsoft managed, currently there is no ability to create user defined objects. There are quite a number of NSG tags (link included to view these), common ones include:
- VirtualNetwork: Includes all virtual network address spaces that are connected to the NSG, including peered networks and those also connected via a gateway.
- AzureLoadBalancer: The Azure virtual load balancer resource translates to the virtual IP address of: 126.96.36.199, if using NSG log monitoring it will show up a lot of traffic from this source – this is the IP where the health probe originates.
- Internet: The IP addressing space that is outside the virtual network which is publicly routable.
- AzureCloud: A great new addition to NSG tags, this includes all Azure datacentre public IP addresses. Even better, you can be region specific with this as well, for example:
AzureCloud.WestEU would allow access to West EU region Azure Pubic IP addresses.
Further service tags info.
7. Application Security Groups (ASGs)
ASGs are used within a NSG to apply a network security rule to a specific workload or group of VMs – defined by ASG worked as being the “network object” & expilicit IP addresses are added to this object. This provides the capability to group VMs into associated groups or workloads, simplifying the NSG rule definition process. Another great use of this is for scalability, creating the virtual machine and assigning the newly created virtual machine to its ASG will provide it with all the NSG rules in place for that specific ASG – zero distribution to your service!
8. Default NSG rules
There are default NSG rules for both inbound and outbound traffic even if you deploy a blank NSG, numbered 65000, 65001 & 65500 – if no previous rule has a deny, these default rules will be used, they are:
Please note – these rules are default even if NSG is completely empty
Be careful when defining NSG rules as you could lose connectivity to the VM or to an additional outbound destination that is part of your environment.
9. NSG Flow logging
Flow logging (Network interface logging level) is a feature within Azure network watcher for NSGs. Once enabled it outputs the flow logs to a storage account that you assigned during configuration. Flow log information is viewed in JSON format. The output consists of both ingress and egress traffic, showing flows on a per rule basis.
10. 188.8.131.52 – What is that IP?
Enabled NSG flow logging – see this suspicious IP? Don’t worry!
This Public IP belongs to Microsoft used for basic infrastructure services including DHCP, DNS and health monitoring (including Azure LoadBalancer) – this IP is used in all regions for this purpose.