|Azure NSG – Blog No 1|
|Time to Read|
|Who should read this blog?|
|If you want to understand NSG in simple words.|
By default, each VM or service can talks to each other in the same virtual network and they can talk to the internet in only outbound direction(default internet outbound).
A Virtual Network could be based mainly on the scale of the services being deployed in that virtual network, hence a requirement emerged to slice a virtual network into smaller addresses called subnets.
An example could be I have two different production websites which are hosted in the same virtual network. One website is developed in Java code and runs on Linux OS while another website is developed in ASP.net and runs on Windows servers. I can create different subnets based on the prefix-size requirement for this use case. The first subnet I can use to deploy the Linux VMs with the Java website and the second subnet can be used to deploy the Windows VMs with the ASP.net website.
Now by default resources in two different subnets in the same Vnet can talk to each other. But in the real-world one may not like that. Like in my above example, I would not want my one website resource talking to another website resource as both are separate websites. Network Security Group(NSG) to the rescue!. For Network engineers it is just like an access control list however stateful as ACLs are stateless.
NSG and its role
As I discussed a requirement above, there must be some way to restrict communication in the same Vnet on the subnet level.
We can configure an NSG and apply it on the subnet level. This way any traffic entering or leaving the subnet would be put against the NSG and the rules we define in it. based on the rules a specific traffic flow can be allowed or restricted.
Now requirements might emerge that we want to block the traffic on an individual VM or a service within the subnet. Nothing to worry about! NSG covers that as well.
Configure and apply NSG on the specific virtual nic (vnic) of the VM where you want to control the traffic.
So for simplicity, we can call them, Subnet NSG which is applied on the subnet, and Nic NSG which is applied on the network interface of the VM. In reality, there is no difference between NSGs that are applied on the subnet or nic, even the same NSG can be applied on both the subnet and Vnic of the VM.
Note:NSG applied on the subnet level will be inherited by all the VM’s vnic in that subnet which means even the subnet NSG would be able to block the traffic between the VM’s within the same subnet if it has the rule to do so. However default NSG if not modified will allow the access between the VM’s within the same subnet but it has a default rule to do so.
NSG applied on the subnet level will be inherited by all the VM’s vnic in that subnet which means even the subnet NSG would be able to block the traffic between the VM’s within the same subnet if it has the rule to do so.
If you apply a different NSG on the Vnic of a VM, in that case, it would have 2 NSGs on its vnic , one inherited from subnet NSG and another applied on the Vnic itself.
Hence, it is important that they don’t conflict with each other.
Note:Unless you have a specific reason to, we recommend that you associate a network security group to a subnet, or a network interface, but not both. Since rules in a network security group associated to a subnet can conflict with rules in a network security group associated to a network interface, you can have unexpected communication problems that require troubleshooting.
vNIC and Subnet NSG together
The above diagram will help us to understand this concept with ease.
In the diagram, the green box is the virtual network 172.16.0.0/16 boundary.
In the virtual network, we have two different subnets –
subnet1(blue box) -172.16.1.0/24 – Subnet-NSG(Red) applied
- Has one VM with IP address 172.16.1.5 on its vnic
- vnic NSG applied for VM
subnet2(Red box) -172.16.2.0/24 – Subnet-NSG(Red) applied
- Has 2 VMs with IP addresses 172.16.2.5 and 172.16.2.6 on its vnic and
- vnic NSG applied for both the VM’s
I know we seldom follow the recommendations and as a cloud engineer, I have seen umpteen times where the same or different NSGs are applied on both the subnet and vnic level.
if it is the same NSG that is applied on the subnet and vnic level it does not make any difference. If traffic is allowed in the NSG it is allowed both at the subnet and vnic level as the same NSG rule is playing on both levels.
However, if different NSGs are applied on both the subnet and vnic levels here is how they play together.
For Inbound Traffic
As the below diagram shows for any incoming traffic to the VM
- First traffic will be tested against the subnet NSG if the subnet NSG denies the traffic. traffic will be dropped. No access is allowed to the VM
- If Subnet NSG allows the traffic it will be tested against the Vnic NSG if it denies the traffic. traffic will be dropped. No access is allowed to the VM
- If Vnic NSG allows the traffic, access to the VM is allowed.
- In conclusion, both the NSGs should be configured to allow the traffic if any one NSG denies the traffic, no access to the VM is possible.
For Outbound Traffic
As the below diagram shows for any outgoing traffic from the VM
- First traffic will be tested against the vNIC NSG if the vNIC NSG denies the traffic. traffic will be dropped. No access is allowed from the VM to the outside world.
- If vNet NSG allows the traffic it will be tested against the Subnet NSG if it denies the traffic. traffic will be dropped. No access is allowed from the VM to the outside world.
- If Subnet NSG allows the traffic, access from the VM is allowed.
- In conclusion, both the NSGs should be configured to allow the traffic if any one NSG denies the traffic, no access from the VM to the outside world is possible.
For more details kindly refer to the Microsoft Page
NSG is an excellent choice for securing virtual networks in the cloud. Whether you are a small business or a large enterprise, incorporating NSG into your security strategy can help you safeguard your data and applications and provide a secure computing environment for your organization.