Azure Firewall vs Network Security Groups (NSG)

Network Security Group (NSG):

A NSG filters traffic at the network layer from and to Azure VNet and consists of security rules that allows or denies traffic based on 5-tuple information:
1. Protocol — such as TCP, UDP, ICMP
2. Source — IP address,
3. Source port
4. Destination
5. Destination port

You can associate an NSG with a subnet or the network interface of an Azure VM. In accordance with Best practices, it’s recommended to scope NSGs at the subnet level or network interface, not both. This can make it complicated when having to troubleshoot network issues

Application Security Groups (ASGs)

An ASG is a logical grouping of virtual machines that allows you to apply security rules at scale. For example, if you have a group of VM’s serving a web application, the VM’s can be placed in an ASG called “webappvms”. The webappvms group can then be added to a rule within an NSG allowing HTTP (TCP) traffic over port 80. This alleviates the need to add individual IP addresses to the security rule.

Azure Firewall

Azure Firewall is a highly available, managed firewall service that filters network and application level traffic. It has the ability to process traffic across subscriptions and VNets that are deployed in a hub-spoke model.

Azure Firewall and NSG Comparison

An NSG is a firewall, but a very basic one. It’s a software defined solution that filters traffic at the Network layer. However, Azure Firewall is more robust. It’s a managed firewall service that can filter and analyze L3-L4 traffic, as well as L7 application traffic. Azure Firewall provides the same capabilities as an NSG, plus more. The following chart offers a comparative illustration of each solution:

• Service Tags — A service tag represents a group of IP address prefixes from a given Azure service. Microsoft manages the address prefixes encompassed by the service tag and automatically updates the service tag as addresses change, minimizing the complexity of frequent updates to network security rules.

You can use service tags to define network access controls on network security groups or Azure Firewall. Use service tags in place of specific IP addresses when you create security rules. By specifying the service tag name, such as ApiManagement, in the appropriate source or destination field of a rule, you can allow or deny the traffic for the corresponding service.

• FQDN Tags — An FQDN tag represents a group of fully qualified domain names (FQDNs) associated with well known Microsoft services. You can use an FQDN tag in application rules to allow the required outbound network traffic through your firewall.

For example, to manually allow Windows Update network traffic through your firewall, you need to create multiple application rules per the Microsoft documentation. Using FQDN tags, you can create an application rule, include the Windows Updates tag, and now network traffic to Microsoft Windows Update endpoints can flow through your firewall. Like Service tags, they are maintained by Microsoft and cannot be customized.

• SNAT — Source Network Address Translation is a feature of Azure Firewall. It’s possible to configure Azure Firewall with a Public IP address (PIP) that can be used to masked the IP address of Azure Resources that are sending out via the Firewall.
• DNAT –Destination Address Translation is used to translate incoming traffic to the firewall’s Public IP to the Private IP addresses of the VNet.

Azure Firewall and NSG in Conjuction

NSGs and Azure Firewall work very well together and are not mutually exclusive or redundant. You typically want to use NSGs when you are protecting network traffic in or out of a subnet. An example would be a subnet that contains VMs that require RDP access (TCP over 3389) from a Jumpbox. Azure Firewall is the solution for filtering traffic to a VNet from the outside. For this reason, it should be deployed in it’s own VNet and isolated from other resources. Azure Firewall is a highly available solution that automatically scales based on its workload. Therefore, it should be in a /26 size subnet to ensure there’s space for additional VMs that are created when it’s scaled out.

A scenario to use both would be a Hub-spoke VNet environment with incoming traffic from the outside. Consider the following diagram:

The above model has Azure Firewall in the Hub VNet which has peered connections to two Spoke VNets. The Spoke Vnets are not directly connected, but their subnets contain a User Defined Route (UDR) that points to the Azure Firewall, which serves as a gateway device. Also, Azure Firewall is public facing and is responsible for protecting inbound and outbound traffic to the VNet. This is where features like Application rules, SNAT and DNaT come in handy. If you have a simple environment, then NSGs should be sufficient for network protection.