Skip to main content

Technical Lab: Configure Azure Firewall Rules

Questions​

Question 1 — Multiple Choice​

A security team needs to allow internal VMs to exclusively access the endpoint https://updates.contoso.com on port 443, blocking any other HTTPS destination. Azure Firewall Standard is deployed as the central egress point of the VNet.

What type of rule should be created to meet this requirement with the least possible permission scope?

A) Network rule allowing traffic on port 443 with destination to the resolved IP address of updates.contoso.com.

B) Application rule allowing the FQDN updates.contoso.com on port 443 with protocol Https.

C) Network rule allowing traffic on port 443 with destination to the Internet service tag.

D) NAT (DNAT) rule redirecting outbound traffic on port 443 to the IP address of updates.contoso.com.

Question 2 — Technical Scenario​

An administrator configured the following policy in Azure Firewall to allow development VMs to access Linux package repositories:

Type: Application Rule
Name: allow-linux-repos
Source: 10.10.2.0/24
Protocol: Http:80, Https:443
Target FQDNs:
  - *.ubuntu.com
  - *.debian.org
  - *.snapcraft.io
Action: Allow

After deployment, VMs can download packages via HTTPS, but fail when trying to update via HTTP. The firewall is logging block events with the default deny rule.

What is the most likely cause of the problem?

A) Application rules in Azure Firewall do not support multiple protocols in the same rule; separate rules for HTTP and HTTPS are required.

B) The Http:80 protocol in application rules requires Azure Firewall to be in Premium tier with TLS inspection enabled to function correctly.

C) The VMs do not have a user-defined route (UDR) pointing HTTP traffic (port 80) to the Azure Firewall private IP, while HTTPS traffic is already being routed correctly.

D) Application rules in Azure Firewall only process traffic that passes through the internal application proxy, and direct HTTP connections from VMs are not intercepted without additional transparent proxy configuration.

Question 3 — Multiple Choice​

An Azure Firewall policy contains the following network rules in a single rule collection:

Collection Priority: 200
Collection Action: Allow

Rule 1: Source 10.0.1.0/24 | Target 10.0.2.0/24 | Port 443 | Allow
Rule 2: Source 10.0.1.0/24 | Target 10.0.2.0/24 | Port Any  | Allow
Rule 3: Source 10.0.1.0/24 | Target Any          | Port 443  | Deny

A VM at 10.0.1.10 attempts to access a server at 10.0.2.50 on port 443. What will be the result?

A) The connection will be blocked by Rule 3, as it has destination Any and is more comprehensive than Rule 1.

B) The connection will be allowed by Rule 1, as within a collection rules are evaluated in order and the first match is applied.

C) The connection will be allowed by Rule 2, as it covers any port and takes precedence over more specific rules within the same collection.

D) Azure Firewall will return a configuration error, as it is not permitted to have Allow and Deny rules in the same rule collection.

Question 4 — True or False​

In an Azure Firewall policy, network rules have precedence over application rules in processing order, which means that if HTTPS traffic is allowed by a network rule, it will not be evaluated by application rules.

True or False?

Question 5 — Technical Scenario​

A company exposes an internal web server (10.1.0.10:80) to external users through a DNAT rule in Azure Firewall. The firewall's public IP is 20.50.100.1. The rule is configured as follows:

Type: DNAT Rule
Name: inbound-web
Target public IP: 20.50.100.1
Target port: 80
Translated IP: 10.1.0.10
Translated port: 80
Protocol: TCP

External users can access the server normally. However, when investigating the web server logs, the operations team notices that all accesses arrive with source IP 20.50.100.x (an Azure Firewall IP), and not with the real IPs of external clients.

What is the technical explanation for this behavior?

A) Azure Firewall automatically applies SNAT to traffic undergoing DNAT, replacing the client's source IP with the firewall's private IP before forwarding the packet to the internal server.

B) The behavior indicates incorrect configuration: the DNAT rule should include the client's source IP field to preserve the original address.

C) The web server is receiving packets with the client's original IP, but the VM's operating system is displaying the firewall's IP due to a local reverse proxy configuration.

D) This behavior only occurs when Azure Firewall Standard is used; Premium preserves the client's source IP in DNAT connections by default.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

Application rules are the correct mechanism for controlling access to specific FQDNs in Azure Firewall. They allow specifying the destination as an FQDN with protocol and port, and the firewall dynamically resolves and tracks the FQDN, covering IP changes without the need for manual rule updates.

Alternative A creates direct coupling to an IP address that may change, and is not the mechanism designed for domain name filtering. Alternative C is excessively permissive, allowing any HTTPS destination on the internet. Alternative D confuses DNAT, which is used for inbound address translation, with outbound FQDN traffic control.

Answer Key — Question 2​

Answer: C

Azure Firewall only inspects and applies rules to traffic that is explicitly routed to it via UDR (User Defined Route). If the route table of the development VMs only forwards traffic destined for port 443 to the firewall IP, traffic on port 80 will follow the system default route, not passing through the firewall. As a result, the application rule is never evaluated for this traffic and it may be blocked or routed incorrectly.

Alternative A is wrong: application rules support multiple protocols in the same rule without restriction. Alternative B is wrong because Http:80 in application rules works in Standard without TLS inspection, which is only relevant for HTTPS. Alternative D describes behavior that does not correspond to Azure Firewall's operation, which intercepts traffic routed to it without the need for additional transparent proxy configuration.

Answer Key — Question 3​

Answer: B

Within a rule collection in Azure Firewall, rules are evaluated in sequential order and the first match determines the result. Rule 1 matches traffic from 10.0.1.10 to 10.0.2.50 on port 443 before Rule 3 is evaluated. Therefore, the connection is allowed.

Alternative A represents a common misconception: the comprehensiveness of the destination does not determine precedence; the evaluation order within the collection is the deciding factor. Alternative C is wrong for the same reason: more comprehensive rules do not take precedence over more specific rules when they appear later in the order. Alternative D is wrong: a rule collection has a single action (Allow or Deny) that applies to the entire collection; it is not possible to have mixed actions within the same collection, which means Rule 3 with Deny action in an Allow collection would be invalid or ignored, reinforcing that Rule 1 prevails.

Answer Key — Question 4​

Answer: True

Azure Firewall's processing order is: first DNAT rules, then network rules, and lastly application rules. If a traffic flow is matched and allowed by a network rule, processing ends there and application rules are not evaluated for that flow.

This sequence has important practical implications: an excessively permissive network rule for HTTPS traffic can inadvertently bypass application rules that restrict specific FQDNs. The correct design for granular HTTPS egress control is to avoid broad network rules on port 443 and use exclusively application rules for this traffic.

Answer Key — Question 5​

Answer: A

This is the expected and documented behavior of Azure Firewall. When a DNAT rule is processed, the firewall automatically applies SNAT to the translated traffic, replacing the external client's source IP with the firewall's own private IP before forwarding the packet to the internal server. This occurs because the internal server needs to return response traffic through the firewall, and SNAT ensures that the return is routed correctly.

The practical consequence is that the internal server never sees the external client's real IP directly. To preserve the source IP, the architectural solution is to use an HTTP header X-Forwarded-For via proxy or Application Gateway in front of the server. Alternative B is wrong because there is no source IP preservation field in Azure Firewall DNAT rules. Alternatives C and D describe behaviors that do not correspond to the platform.