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(2/3) ?
Hello everyone, this post is a continuation to my previous article covering NSG Fundamentals:
So,now I am covering the logical question that may arise in one’s mind:
If I have a sample Linux webserver running in Azure(eg. Flipkart.com website) and want people on internet(clients) to load the product catalog, what kind of NSG rules are needed to be configured to allow traffic?
Before answering the above, there are 2 misconceptions requiring clarification/fundamentals to be known:
1. NSG rules are STATEFUL in nature:
A flow record is created for existing connections. Communication is allowed or denied based on the connection state of the flow record.
The flow record allows a network security group to be stateful.
If you specify an outbound security rule to any address over port 80, for example, it’s not necessary to specify an inbound security rule for the response to the outbound traffic.
You only need to specify an inbound security rule if communication is initiated externally.
The opposite is also true. If inbound traffic is allowed over a port, it’s not necessary to specify an outbound security rule to respond to traffic over the port.
In summary,one needs to analyze who needs to INITIATE the traffic.
In example above, the clients(Internet users) need to initiate a connection for a web page towards the Azure server.
Hence,we require an inbound rule for the NSG allowing connections sourced from any Internet IP(*) going towards public IP addresss of the Azure Web Server.
Further,How will the Azure server reply back to this request of the client?Do you need an Outbound Allow Rule?
Answer is a NO, NSG rules are STATEFUL in nature, meaning that Azure remembers what was allowed on one side and always allows the REPLY traffic to be allowed.
Please take a moment and digest this!
It is worth noting that even if you place a DENY ALL outbound, the above communication would still work due to the simple fact that the OUTBOUND rule is not seen in the above communication example, REPLY traffic gets allowed without referring to any NSGs.
So,summarizing the above, we have a rule looking like this:
(apply at Subnet or NIC level)
Once again, NO OUTBOUND RULES needed.
Another note point in the table, I mentioned PRIVATE IP and NOT Public IP above for the VM.
Network security groups are processed after Azure translates a public IP address to a private IP address for inbound traffic, and before Azure translates a private IP address to a public IP address for outbound traffic.
2.Client Server Model:
When a client connects to a server (Linux or windows server for example, in cloud), a random port from the ephemeral port range (1024–65535) becomes the client’s source port.
The designated ephemeral port becomes the destination port for return traffic from the service.
The server always listens for incoming traffic on fixed ports:
22 for SSH, 80/443 for HTTP or HTTPS ,3389 for RDP
[Client refers to a device/application requesting for a service eg.your laptop and Server refers to the device/application serving your request eg.the server hosted by flipkart.com which contains different products’ catalog]
Hence,in the table above, we applied destination side to listen for traffic on port 443 ie traffic flows from Internet Clients(any port) to destination server(fixed port,443 in this example).
Note that source port is marked as * since its a random port that will be chosen for communication, unknown at time of creation of this rule.
It must,of course, be noted that the PCs initiating the web traffic to Azure VM do not block traffic going out towards Azure server by use of firewalls,either within the OS or custom deployed firewalls(Not the case for most demo testing in your lab).
Thats pretty much it for this post, I will cover a small example and the default NSG rules created by Azure in my next post.
