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 in 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

Configuring rules in the Azure Firewall [Image Credit: Aidan Finn]

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.