As mentioned in a previous blog – NSG’s control access by permitting or denying network traffic in a number of ways, whether it be:-
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!
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!
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”
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.
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.
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:
AzureCloud.WestEU would allow access to West EU region Azure Pubic IP addresses.
Further service tags info.
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!
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.
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.
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.