Configure Azure Firewall rules
You can configure NAT rules, network rules, and applications rules on Azure Firewall using either classic rules or Firewall Policy. Azure Firewall denies all traffic by default, until rules are manually configured to allow traffic. The rules are terminating, so rule processing stops on a match.
Rule processing using classic rules
Rule collections are processed according to the rule type in priority order, lower numbers to higher numbers from 100 to 65,000. A rule collection name can have only letters, numbers, underscores, periods, or hyphens. It must begin with a letter or number, and end with a letter, number, or underscore. The maximum name length is 80 characters.
It's best to initially space your rule collection priority numbers in 100 increments (100, 200, 300, and so on) so you have room to add more rule collections if needed.
Rule processing using Firewall Policy
With Firewall Policy, rules are organized inside Rule Collections and Rule Collection Groups. Rule Collection Groups contain zero or more Rule Collections. Rule Collections are type NAT, Network, or Applications. You can define multiple Rule Collection types within a single Rule Group. You can define zero or more Rules in a Rule Collection. Rules in a Rule Collection must be of the same type (NAT, Network, or Application).
Rules are processed based on Rule Collection Group Priority and Rule Collection priority. Priority is any number between 100 (highest priority) to 65,000 (lowest priority). Highest priority Rule Collection Groups are processed first. Inside a rule collection group, Rule Collections with highest priority (lowest number) are processed first.
If a Firewall Policy is inherited from a parent policy, Rule Collection Groups in the parent policy always takes precedence regardless of the priority of a child policy.
Note
Application rules are always processed after Network rules, which are processed after DNAT rules regardless of Rule collection group or Rule collection priority and policy inheritance.
So, to summarize:
Parent policy always takes precedence.
- Rule collection groups are processed in priority order.
- Rule collections are processed in priority order.
- DNAT rules, then Network rules, then Application rules are processed.
Here's an example policy:
Assuming BaseRCG1 is a rule collection group priority (200) that contains the rule collections: DNATRC1, DNATRC3,NetworkRC1.
BaseRCG2 is a rule collection group priority (300) that contains the rule collections: AppRC2, NetworkRC2.
ChildRCG1 is a rule collection group priority (300) that contains the rule collections: ChNetRC1, ChAppRC1.
ChildRCG2 is a rule collection group priority (650) that contains the rule collections: ChNetRC2, ChAppRC2,ChDNATRC3.
As per following table:
| Name | Type | Priority | Rules | Inherited from |
|---|---|---|---|---|
| BaseRCG1 | Rule collection group | 200 | 8 | Parent policy |
| DNATRC1 | DNAT rule collection | 600 | 7 | Parent policy |
| DNATRC3 | DNAT rule collection | 610 | 3 | Parent policy |
| NetworkRC1 | Network rule collection | 800 | 1 | Parent policy |
| BaseRCG2 | Rule collection group | 300 | 3 | Parent policy |
| AppRC2 | Application rule collection | 1200 | 2 | Parent policy |
| NetworkRC2 | Network rule collection | 1300 | 1 | Parent policy |
| ChildRCG1 | Rule collection group | 300 | 5 | - |
| ChNetRC1 | Network rule collection | 700 | 3 | - |
| ChAppRC1 | Application rule collection | 900 | 2 | - |
| ChildRCG2 | Rule collection group | 650 | 9 | - |
| ChNetRC2 | Network rule collection | 1100 | 2 | - |
| ChAppRC2 | Application rule collection | 2000 | 7 | - |
| ChDNATRC3 | DNAT rule collection | 3000 | 2 | - |
Initial Iteration for DNAT Rules:
The process begins by examining the rule collection group (RCG) with the lowest number, which is BaseRCG1 with a priority of 200. Within this group, it searches for DNAT rule collections and evaluates them according to their priorities. In this case, DNATRC1 (priority 600) and DNATRC3 (priority 610) are found and processed accordingly.
Next, it moves to the next RCG, BaseRCG2 (priority 300), but finds no DNAT rule collection.
Following that, it proceeds to ChildRCG1 (priority 300), also without a DNAT rule collection.
Finally, it checks ChildRCG2 (priority 650) and finds the ChDNATRC3 rule collection (priority 3000).
Iteration for NETWORK Rules:
Returning to BaseRCG1, the iteration continues, this time for NETWORK rules. Only NetworkRC1 (priority 800) is found.
Then, it moves to BaseRCG2, where NetworkRC2 (priority 1300) is located.
Moving on to ChildRCG1, it discovers ChNetRC1 (priority 700) as the NETWORK rule.
Lastly, in ChildRCG2, it finds ChNetRC2 (priority 1100) as the NETWORK rule collection.
Final Iteration for APPLICATION Rules:
Returning to BaseRCG1, the process iterates for APPLICATION rules, but none are found.
In BaseRCG2, it identifies AppRC2 (priority 1200) as the APPLICATION rule.
In ChildRCG1, ChAppRC1 (priority 900) is found as the APPLICATION rule.
Finally, in ChildRCG2, it locates ChAppRC2 (priority 2000) as the APPLICATION rule.
In summary, the rule processing sequence is as follows: DNATRC1, DNATRC3, ChDNATRC3, NetworkRC1, NetworkRC2, ChNetRC1, ChNetRC2, AppRC2, ChAppRC1, ChAppRC2.
This process involves analyzing rule collection groups by priority, and within each group, ordering the rules according to their priorities for each rule type (DNAT, NETWORK, and APPLICATION).
So first all the DNAT rules are processed from all the rule collection groups, analysing the rule collection groups by order of priority and ordering the DNAT rules within each rule collection group by order of priority. Then the same process for NETWORK rules, and finally for APPLICATION rules.
For more information about Firewall Policy rule sets, see Azure Firewall Policy rule sets.
Threat Intelligence
If you enable threat intelligence-based filtering, those rules are highest priority and are always processed first (before network and application rules). Threat-intelligence filtering may deny traffic before any configured rules are processed. For more information, see Azure Firewall threat intelligence-based filtering.
IDPS
When IDPS is configured in Alert mode, the IDPS engine works in parallel to the rule processing logic and generates alerts on matching signatures for both inbound and outbound flows. For an IDPS signature match, an alert is logged in firewall logs. However, since the IDPS engine works in parallel to the rule processing engine, traffic denied or allowed by application/network rules may still generate another log entry.
When IDPS is configured in Alert and Deny mode, the IDPS engine is inline and activated after the rules processing engine. So both engines generate alerts and may block matching flows.
Session drops done by IDPS blocks the flow silently. So no RST is sent on the TCP level. Since IDPS inspects traffic always after the Network/Application rule has been matched (Allow/Deny) and marked in logs, another Drop message may be logged where IDPS decides to deny the session because of a signature match.
When TLS inspection is enabled both unencrypted and encrypted traffic is inspected.
Outbound connectivity
Network rules and applications rules
If you configure network rules and application rules, then network rules are applied in priority order before application rules. The rules are terminating. So, if a match is found in a network rule, no other rules are processed. If configured, IDPS is done on all traversed traffic and upon signature match, IDPS may alert or/and block suspicious traffic.
Application rules then evaluate the packet in priority order if there's no network rule match, and if the protocol is HTTP, HTTPS, or MSSQL.
For HTTP, Azure Firewall looks for an application rule match according to the Host header. For HTTPS, Azure Firewall looks for an application rule match according to SNI only.
In both HTTP and TLS inspected HTTPS cases, the firewall ignores the packet's destination IP address and uses the DNS resolved IP address from the Host header. The firewall expects to get port number in the Host header, otherwise it assumes the standard port 80. If there's a port mismatch between the actual TCP port and the port in the host header, the traffic is dropped. DNS resolution is done by Azure DNS or by a custom DNS if configured on the firewall.
Note
Both HTTP and HTTPS protocols (with TLS inspection) are always filled by Azure Firewall with XFF (X-Forwarded-For) header equal to the original source IP address.
When an application rule contains TLS inspection, the firewall rules engine process SNI, Host Header, and also the URL to match the rule.
If still no match is found within application rules, then the packet is evaluated against the infrastructure rule collection. If there's still no match, then the packet is denied by default.
Note
Network rules can be configured for TCP, UDP, ICMP, or Any IP protocol. Any IP protocol includes all the IP protocols as defined in the Internet Assigned Numbers Authority (IANA) Protocol Numbers document. If a destination port is explicitly configured, then the rule is translated to a TCP+UDP rule. Before November 9, 2020, Any meant TCP, or UDP, or ICMP. So, you might have configured a rule before that date with Protocol = Any, and destination ports = '*'. If you don't intend to allow any IP protocol as currently defined, then modify the rule to explicitly configure the protocol(s) you want (TCP, UDP, or ICMP).
Inbound connectivity
DNAT rules and Network rules
Inbound Internet or intranet (preview) connectivity can be enabled by configuring Destination Network Address Translation (DNAT) as described in Filter inbound Internet or intranet traffic with Azure Firewall DNAT using the Azure portal. NAT rules are applied in priority before network rules. If a match is found, the traffic is translated according to the DNAT rule and allowed by the firewall. So the traffic isn't subject to any further processing by other network rules. For security reasons, the recommended approach is to add a specific Internet source to allow DNAT access to the network and avoid using wildcards.
Application rules aren't applied for inbound connections. So, if you want to filter inbound HTTP/S traffic, you should use Web Application Firewall (WAF). For more information, see What is Azure Web Application Firewall?
Examples
The following examples show the results of some of these rule combinations.
Example 1
Connection to google.com is allowed because of a matching network rule.
Network rule
- Action: Allow
| name | Protocol | Source type | Source | Destination type | Destination address | Destination ports |
|---|---|---|---|---|---|---|
| Allow-web | TCP | IP address | * | IP address | * | 80,443 |
Application rule
- Action: Deny
| name | Source type | Source | Protocol:Port | Target FQDNs |
|---|---|---|---|---|
| Deny-google | IP address | * | http:80,https:443 | google.com |
Result
The connection to google.com is allowed because the packet matches the Allow-web network rule. Rule processing stops at this point.
Example 2
SSH traffic is denied because a higher priority Deny network rule collection blocks it.
Network rule collection 1
- Name: Allow-collection
- Priority: 200
- Action: Allow
| name | Protocol | Source type | Source | Destination type | Destination address | Destination ports |
|---|---|---|---|---|---|---|
| Allow-SSH | TCP | IP address | * | IP address | * | 22 |
Network rule collection 2
- Name: Deny-collection
- Priority: 100
- Action: Deny
| name | Protocol | Source type | Source | Destination type | Destination address | Destination ports |
|---|---|---|---|---|---|---|
| Deny-SSH | TCP | IP address | * | IP address | * | 22 |
Result
SSH connections are denied because a higher priority network rule collection blocks it. Rule processing stops at this point.
Rule changes
If you change a rule to deny previously allowed traffic, any relevant existing sessions are dropped.
Three-way handshake behavior
As a stateful service, Azure Firewall completes a TCP three-way handshake for allowed traffic, from a source to the destination. For example, VNet-A to VNet-B.
Creating an allow rule from VNet-A to VNet-B doesn't mean that new initiated connections from VNet-B to VNet-A are allowed.
As a result, there's no need to create an explicit deny rule from VNet-B to VNet-A.