Azure Firewall vs. NSG: Your Choice Depends on Your Use Case
Network security and control of traffic flow in and out of resources within Azure are imperative to manage organizations’ overall cloud security architecture. Azure Firewall and Network Security Groups (NSGs) are the Microsoft solutions for Azure network security. Azure Firewall is an intelligent firewall service that provides threat protection for workloads running in Azure. In contrast, an NSG filters network traffic among Azure resources in a Virtual Network (VNet). Together, they provide superior “defense-in-depth” network security.
This article defines and describes Azure Firewall and NSGs, describes the differences between them, and recommends deployment best practices for the two solutions.
Executive summary
The table below outlines the key concepts this article covers to help readers understand.
| Term | Description |
|---|---|
| 5-Tuple Hash | NSGs filter inbound and outbound traffic based on a hash of these five fields: Source IP, Source Port, Destination IP, Destination Port, and Protocol. |
| Application Security Group (ASG) | ASGs protect sets of VMs with common functions by grouping them and defining the required security rules. For example, it is possible to group all web servers into an ASG, specify the appropriate security rules, and use the ASG as a source or destination on NSGs. As a result, NSG’s security rules will apply to all ASG members. |
| Destination Network Address Translation (DNAT) | DNAT is an Azure firewall feature to translate traffic coming into the firewall’s public IP to the private IP addresses of the VNet. The traffic appears to internal resources as if it originated from Azure Firewall’s private IP address. |
| Fully Qualified Domain Names (FQDN) Tags | An FQDN tag represents a group of fully qualified domain names of Microsoft services. Microsoft manages the FQDNs encompassed by the FQDN tag and updates the tag as FQDNs change. You can use FQDN tags in application rules to allow outbound traffic into the network through Azure Firewall. Examples: Windows Update, Azure Backup, Azure Kubernetes Service (AKS), WindowsDiagnostics. |
| Intrusion Detection and Prevention System (IDPS) | IDPS provides the ability to monitor network traffic for malicious activities and log and block traffic. |
| Open Systems Interconnection (OSI) Model | The OSI model is the standard seven-layer model used to define the interaction of protocols that computers use to communicate in a network. |
| Rule Collection | This is a set of Azure Firewall rules that share the same order and priority. |
| 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 on Azure Firewall, NSGs, and UDRs. Examples: APiManagement, Storage, AzureCloud, Internet. |
| Source Network Address Translation (SNAT) | SNAT is an Azure Firewall feature to mask source IP addresses (e.g., virtual machine IP addresses) that are sending traffic. The traffic appears to destinations as if it originated from Azure Firewall’s public IP address. SNAT also allows multiple computers to access the Internet from a single public IP. |
| Threat intelligence | This feature provides the ability to alert and deny traffic from/to known malicious IPs and domains. |
| TLS inspection | TLS inspection allows decryption and encryption of data for inspection and processing. |
| URL filtering | This feature is an extension to Azure Firewall’s FQDN filtering that allows filtering of the entire URL. |
| Web categories | This feature provides the ability to block website categories such as gambling, social media, etc. |
Azure Firewall
Azure Firewall is a scalable, intelligent firewall service in Azure that provides east-west and north-south traffic inspection, filtering, and monitoring. Azure Firewall inspects traffic on Layers 3 to 7 and can alert and deny traffic in real time from/to known malicious IP addresses and domains.
Azure Firewall topology and functionality (source)
Azure Firewall supports DNAT, application, and network rules. DNAT rules translate and filter inbound Internet traffic to Azure subnets. Application rules work with fully qualified domain names (FQDNs), and network rules filter traffic based on the Source Address, Protocol, Destination Port, and Destination Address fields. In addition, Azure Firewall supports TLS inspection, IDPS, URL filtering, and web categories.
Destination Network Address Translation (DNAT)
DNAT rules help organizations translate and filter inbound Internet traffic to internal resources. The rules translate the firewall’s public IP address and port to a private IP address and port.
The screenshots below depict a DNAT rule named “MyWebSite” that allows TCP traffic to the firewall’s public IP address on port 80 from “Any” source to access the internal web server (10.12.67.24) on port 80.
DNAT rule to allow inbound traffic to the internal web site
Application rules
Application rules allow or deny outbound access to specific FQDNs. Azure Firewall rejects all traffic until rules are manually configured to allow traffic. In other words, browsing www.microsoft.com is denied by default. Similarly, the firewall blocks access to Windows Update and Azure Cloud if not explicitly allowed.
The figure below depicts two application rules to allow HTTP and HTTPS access to all microsoft.com websites.
Application rule to allow outbound traffic to Microsoft web sites
Network rules
Network rules allow or deny access to specific IP addresses. Network rules can use FQDNs based on DNS resolution in Azure Firewall and firewall policies. These FQDNs are then translated to corresponding IP addresses based on the selected DNS server’s resolution.
The figure below depicts a network rule to allow DNS queries to Google’s DNS server 8.8.8.8 on UDP port 53.
Network rule to allow outbound traffic to Google’s DNS server
Rule processing logic
In Azure Firewall, there are three rule collection types: DNAT, network, and application. Rules in a rule collection must be of the same type. You can have zero or more rules in a rule collection and have multiple rule collection types within a single rule group.
Azure Firewall processes DNAT rules first, followed by network and application rules, regardless of rule collection group or priority and policy inheritance.
Azure Firewall’s rule processing order
Within each rule type, rules are processed based on rule collection group priority and rule collection priority. Each rule collection group and rule collection must have a number between 100 and 65,000; the lower the number, the higher the priority. The highest priority rule collection groups are processed first, and the rule collections within a rule collection group with the highest priority are processed first.
Example Azure Firewall policy rules (source)
Azure Firewall will process the example rules above in the following order:
- DNATRC1
- DNATRC3
- ChDNATRC3
- NetworkRC1
- NetworkRC2
- ChNetRC1
- ChNetRC2
- AppRC2
- ChAppRC1
- ChAppRC2
Azure Firewall’s rule processing logic is complex and considers other factors. For example, threat intelligence and IDPS rules take precedence if enabled and configured on the firewall. Please read Rule processing using Firewall Policy on Microsoft docs for more in-depth logic information and detailed explanations.
Azure Firewall SKUs
Azure Firewall is offered in two SKUs:
- Azure Firewall Standard supports DNAT, application and network filtering rules, FQDN and service tags, and threat intelligence. It scales up to 30 Gbps and integrates with availability zones to support a service level agreement (SLA) of 99.99%.
- Azure Firewall Premium includes all standard features and supports TLS inspection, IDPS, URL filtering, and web categories. Support for IDPS signatures and rulesets includes more than 58,000 signatures in over 50 categories, making Azure Firewall Premium suitable for highly sensitive and regulated environments such as the payment and healthcare industries.
Azure Firewall Premium features (Source)
Compared to Next-Generation Firewalls (NGFW) such as Cisco Firepower and Juniper SRX, Azure Firewall is easy to set up and manage, scales on-demand, and provides advanced threat protection. However, Azure Firewall lacks enterprise reporting, logging, and monitoring features compared to NGFWs.
Network Security Groups
An NSG is a group of security rules that filter inbound and outbound traffic to and from Azure resources based on a 5-tuple hash. Allow or deny decisions are processed in priority order based on these fields: Source, Source Port, Destination, Destination Port, and Protocol. These decisions apply to the traffic flow in and out of VNet subnets and network interface cards (NICs).
Figure 8: Network Security Group deployment (Source)
Source, Destination, and Protocol Fields
A source can be Any, IP Addresses, My IP address, Service Tag, or Application security group. A destination can be Any, IP Addresses, Service Tag, or Application security group. The supported protocols are Any, TCP, UDP, and ICMP.
NSG’s Source, Destination, and Protocols
Service tags and application security groups (ASGs) streamline source and destination addresses. Service tags are Microsoft-managed IP prefixes for common Azure services such as LogicApps, SQL, and ServiceBus. ASGs, on the other hand, are user-managed internal IP addresses for common functions such as web and SQL servers.
Rule processing logic
Security rules in NSGs are processed based on priority order. Each rule must have a number between 100 and 4,096; the lower the number, the higher the priority. To demonstrate, let’s look at the three security rules below. The first allows RDP traffic from a specific IP address (10.67.12.4), the second denies RDP from “Any” source, and the third allows all traffic from “Any” source on the internal virtual network. When the network receives an RDP request, the rules will be processed in the order of priority. If RDP traffic comes from 10.67.12.4, it will be allowed, since that’s the highest priority rule. RDP traffic will be rejected if it comes from all other sources, per the RDP_Deny rule.
Note that RDP traffic processing will stop once a match is found. As a result, no RDP traffic request will be processed beyond the second security rule (since it specifies “Any/Any” and will match anything).
NSG rules are processed in priority order
Default security rules
An NSG includes default security rules to allow specific inbound and outbound traffic into the network. For example, inbound traffic to all subnets in a virtual network may be allowed as well as Internet outbound traffic. A default “DenyAllInbound” rule is placed at the end of the inbound rules with a priority of 65,000.
The default security rules can’t be changed or removed, but they can be overridden by creating rules with higher priority.
The table below lists all default NSG inbound and outbound rules.
| Direction | Security Rule | Priority | Description |
|---|---|---|---|
|
Inbound | AllowVnetInBound | 65000 | Allows inbound traffic from the Vnet. |
| AllowAzureLoadBalancerInBound | 65001 | Allows traffic from Azure Load Balancer Health Probe. Traffic is always generated from IP address 168.63.129.16 | |
| DenyAllInbound | 65500 | Denies traffic from any other system outside the Vnet. | |
|
Outbound | AllowVnetOutBound | 65000 | Allows outbound traffic to the Vnet. |
| AllowInternetOutBound | 65001 | Allows outbound traffic to the Internet. | |
| DenyAllOutBound | 65500 | Denies traffic to any other system outside the Vnet.
|
NSG default security rules
State
NSGs are stateful, implying that if an inbound request passes, the outbound request will also pass. For example, if you specify an outbound security rule to any address on port 80, it’s not necessary to specify an inbound security rule for the response to the outbound traffic. You only need to set an inbound security rule if communication is initiated externally. The opposite is also true: Defining an outbound security rule is superfluous if inbound traffic is allowed over a port.
Comparison Tables
NSGs are basic firewall services that filter traffic at Layers 3 and 4 of the OSI model. Azure Firewall, in comparison, is a managed firewall service that filters and analyzes traffic at Layers 3, 4, and 7 of the OSI model. The tables below lay out many areas of comparison for the two solutions.
| Area of Comparison | Azure Firewall | NSG |
|---|---|---|
| Use Case | Protection at the network and application level across different subscriptions and virtual networks. | A packet filtering firewall to limit traffic to resources within virtual networks in each subscription. |
| Deployment | Azure Firewall must be deployed in a dedicated subnet named “AzureFirewallSubnet” in a VNet. In addition, a /26 address space is required to ensure scalability. | NSGs are created outside VNets but must be associated with subnets and/or NICs to take effect on the network. |
| Pricing |
| Free |
| OSI Layers |
|
|
| State | Stateful | |
| Protocol-based filtering |  | |
| Rule processing logic | Complex | Simple |
Azure Firewall and NSG comparison
| Supported Features | Azure Firewall | NSG |
|---|---|---|
| Azure Monitor logging | | |
| ASGs |  | |
| Forced tunneling | | |
| FQDN tags | | |
| IDPS | | |
| Inbound DNAT | | |
| Outbound SNAT | | |
| Service tags | | |
| Threat intelligence | | |
| TLS inspection | | |
| URL filtering | | |
| Web categories | | |
Comparison of Azure Firewall and NSG features
Deployment Scenarios
Organizations can use Azure Firewall, NSGs, or both, depending on the types and sizes of workloads they run in Azure, required functionality, and cost implications to secure and control inbound and outbound traffic flow among Azure resources.
For example, securing traffic flow in a three-tier architecture requires three NSGs associated with the web, business, and data subnets, as shown in the figure below.
NSGs secure traffic flow in a three-tier architecture (source)
In the example above, you would allow inbound HTTP traffic from the Internet to the web tier, inbound traffic from the web tier to the business tier on specific ports, and inbound TCP 1433 traffic from the business to the data tier. Inbound RDP is only allowed on the management subnet. All VMs in the diagram accept RDP TCP 3389 from the jump box.
Suppose the deployment above was for a large company that requires TLS inspection, IDPS, and DNAT. In that case, Azure Firewall would complement the solution and provide the needed features, augmenting the deployment with additional security. The figure below depicts this deployment example.
