Network Security Groups in Azure — The Fundamentals , Which Direction to Apply Rules, What would source and target ports be, Does return reply traffic need to be explicitly permitted(3/3) ?
Welcome to the last installment of my articles on Network Security Groups.
In case you missed, part 2’s link is here:
Network Security Groups in Azure — The Fundamentals , Which Direction to Apply Rules, What would…
Hello everyone, this post is a continuation to my previous article covering NSG Fundamentals:
In this post,I would like to talk about the default rules in NSGs and summarize the last article into a small example.
- Default NSG Rules in Azure:
By default, when a new NSG is created in Azure, there are few INBOUND and OUTBOUND rules that appear by default-
Note the use of Service Tags highlighted in color above.
Service tags are predefined IP addresses representing specific services or resources.
NOTE on the Virtual Network service tag:
(does NOT represent ALL VNETS in Azure)
The virtual network address space (all IP address ranges defined for the virtual network) referencing the vnet where this was defined, all connected on-premises address spaces, peered virtual networks, virtual networks connected to a virtual network gateway, the virtual IP address of the host, and address prefixes used on user-defined routes. This tag might also contain default routes.
Putting the above RULES in words,
i. AllowVNetInBound indicates traffic sourced from within the vnet(same or another subnet) is allowed to flow inbound.
ii. AllowAzureLoadBalancerInBound means allow “Azure Load Balancer Health Probe”.
When an Azure Load Balancer get created, it will probe backend to detect if the backend service is healthy or not.The probe packet is sent from source address “AzureLoadBalancer” . The IP address of “AzureLoadBalancer” is always 18.104.22.168.
So,probes from LB(src) are being allowed inbound into backend VM.
iii.DenyAllInbound indicates that traffic sourced from anywhere will be denied inbound(ie if the rules above this priority of 65500 do not ALLOW traffic IN, this last rule DENIES any other traffic flowing INTO a VM/subnet).
i. AllowVnetOutBound indicates traffic being sent out to a destination in same vnet(same or another subnet) is allowed to flow outbound.
ii. AllowInternetOutBound means that traffic being sent out to Internet is allowed.
Hence,with this default NSG rule, Outbound internet connectivity to achieve tasks such as OS patching(update) is allowed by default.
Also recall that for the Internet patch repository to send a reply back to this VM(with the actual patch), no INBOUND rule is evaluated as NSGs are stateful in nature (reference last post).
iii. DenyAllOutBound indicates that traffic sent to destination ANY will be denied(ie if the rules above this priority of 65500 do not ALLOW traffic to flow OUTBOUND, this last rule DENIES any other traffic flowing OUT of a VM/subnet).
Note that you cannot remove the default rules, but you can override them by creating rules with higher priorities.
Let us now focus our attention on the communication between subnets belonging to same vNet:
Let VM A and VM B belong to two different subnets in same virtual network and objective is to allow VM A to be able to send traffic towards VM B(and VM B should be able to reply back to the same request).
Note in above picture that it is the combination of AllowVNetInBound and AllowVnetOutBound that allows any kind of communication to happen by default within a virtual network(within/across subnets).
Traffic is allowed outbound from a source in the vNET and on reaching the destination side,it is allowed inbound.
As usual,reply traffic does not need explicit rules on either side due to STATEFUL nature.
2.Sample illustration to clarify how NSGs work and strengthen what was learnt in the second post:
Imagine a single vNet with 2 Virtual Machines,VM-A and VM-B.
These VMs reside in 2 different subnets in the same vNet.
There are NSGs applied to both the Subnets with Rules as defined in picture below.
Like a PRODUCTION environment setup, the default AllowVNetInBound and AllowVnetOutBound rules created by Azure have been overridden by creating a DENY rule of lower number(higher priority). This prevents the subnet/NIC to subnet/NIC communication within virtual network to tightly regulate what should be allowed.
2 scenarios have been discussed:
(For a bigger image,kindly right click>>open image in new tab>>zoom in)