The Three Different Types of Rules that are in the Azure Firewall

Block by Default

There are three kinds of rules that you can configure in the Azure Firewall. We’ll delve into these in a few moments, but the first thing you should know is that the Azure Firewall blocks traffic by default. If you do not enable it, it is not allowed … almost entirely … but I’ll explain that later in the post.
The three kinds of rule sets are:

• NAT Rules
• Network Rules
• Application Rules

NAT Rules

The Azure Firewall allows you to share network services with external networks, such as on-premises or the Internet through the inspection and logging of the firewall. This traffic routes through the external public IP address of the firewall. Scenarios that you might consider are publishing SSH, RDP, or non-HTTP/S applications to the Internet.

Microsoft refers to the form of NAT as being Destination Network Address Translation (DNAT). The rules work with the following parameters:

• Name: A label for the rule.
• Protocol: TCP or UDP.
• Source Address: * (Internet), a specific Internet address, or a CIDR block.
• Destination Address: Expect this to be renamed – this refers to the external address of the firewall that the rule will inspect.
• Destination Ports: The TCP or UDP ports that the rule will listen to on the external IP address of the firewall.
• Translated Address: The IP address of the service (virtual machine, internal load balancer, and so on) that privately hosts or presents the service.
• Translated Port: The port that the inbound traffic will be routed to by the Azure Firewall.

Quite often in traditional firewall management, a NAT rule that routes traffic must be accompanied by a matching network rule to allow the traffic. In the case of the Azure Firewall, once you create a NAT rule, the firewall implicitly creates a hidden network rule to reduce your management effort and complexity – I do like this!

Network Rules

Any non-HTTP/S traffic that will be allowed to flow through the firewall must have a network rule – note the above time-saving feature in NAT rules. For example, if I have one subnet with web servers that must talk to a SQL Server in another subnet, then I must have a network rule to allow TCP 1433 from the source subnet to the destination subnet.
The following parameters are used to configure a network rule:

• Name: A friendly label for the rule.
• Protocol: This can be TCP, UDP, ICMP (ping and traceroute) or Any.
• Source Address: The address or CIDR block of the source.
• Destination Addresses: The addresses or CIDR blocks of the destination(s).
• Destination Ports: The destination port of the traffic.

Application Rules

The third and final set of rules deals with HTTP/HTTPS traffic at Layer-7 in the networking stack. Here you will specify what web application traffic you want to allow to flow through the firewall. We will start with Target FQDNs (fully qualified domain names) where you are dealing with non-Microsoft services:

• Name: A friendly label for the rule.
• Source Addresses: The IP address of the source.
• Protocol:Port: Whether this is for HTTP/HTTPS and the port that the web server is listening on.
• Target FQDNs: The domain name of the service, such as petri.com. Note that wildcards can be used, such as *.petri.com (everything at petri.com) or even * (the entire Internet).

There is a second kind of application rule called FQDN Tags, referred to in Microsoft’s documentation as the Infrastructure Rule Collection. Remember that the Azure Firewall blocks everything by default. If you do not specify a domain name or a suitable wildcard, then that traffic is not allowed. As a result, things like Azure Backup or Diagnostics traffic from virtual machines will be blocked if your user-defined routing (UDR) directs that traffic through the Azure Firewall. Microsoft provides a number of FQDN tags that can be used in special application rules to allow this web traffic – this list will probably grow over time:

• AppServiceEnvironment: The private deployment of Azure App Services.
• Azure Backup: Protecting virtual machine-based services.
• MicrosoftActiveProtectionService: Windows Defender Antivirus.
• WindowsDiagnostics: Storing data from VNet-connected resources to a storage account.
• WindowsUpdate: Patching your Windows virtual machines.

How These Rules Are Processed

The three types of rules can be broken down into two sets:

• NAT: This is a routing rule, directing traffic from a public IP address to a private IP address. A hidden network rule is automatically created to allow the traffic.
• Network Rules and Application Rules: These rules specify what traffic is allowed through the Azure Firewall.

So when a packet is being inspected to determine if it is allowed or not (not is the default) then only Network Rules and Application Rules are used for filtering. They are processed in this order:

1. Network Rules
2. Application Rules

In reality, the ordering is a bit more detailed because Application Rules have two types:

1. Network Rules
2. Application Rules – Target FQDNs
3. Application Rules – FQDN Tags

The rules are terminating. Once a positive match is found, allowing the traffic through, no more rules are checked.

FAQs

How does Azure Firewall Rule Type prioritization affect performance in high-traffic environments?

Azure Firewall Rule Types processing prioritization has minimal impact on performance, as the firewall utilizes parallel processing and intelligent caching mechanisms. The rule evaluation typically adds only microseconds of latency, even in environments handling millions of requests per second.

Can Azure Firewall Rule Types be automated or programmatically managed across multiple regions?

Yes, Azure Firewall Rule Types can be managed through Azure ARM templates, PowerShell scripts, or Azure CLI. This allows for automated deployment and synchronization of rules across different regions, ensuring consistent security policies throughout your global infrastructure.

What are the scaling limitations for different Azure Firewall Rule Types?

Each Azure Firewall Rule Types category has specific limits: NAT rules support up to 250 rules per policy, Network rules allow 10,000 entries, and Application rules can handle up to 5,000 target FQDNs per deployment. These limits can be increased through Azure support requests.

How do Azure Firewall Rule Types interact with other Azure security services?

Azure Firewall Rule Types integrate seamlessly with Azure Security Center, Azure Sentinel, and Azure Network Watcher, providing comprehensive security monitoring and threat detection. The rules can be configured to work in conjunction with Azure DDoS protection and Azure Web Application Firewall.

What disaster recovery options are available for Azure Firewall Rule Types configurations?

Azure Firewall Rule Types configurations can be backed up using Azure Backup, exported as templates, or replicated across regions using Azure Site Recovery. This ensures business continuity and quick recovery in case of regional outages or configuration issues.