Troubleshooting Lab: Configure Azure Firewall Rules
Diagnostic Scenarios
Scenario 1 — Root Cause
An operations team configured rules in Azure Firewall to allow VMs in subnet 10.20.1.0/24 to access an external SaaS service via HTTPS. The administrator created the following application rule:
Firewall Policy: policy-prod
Rule Collection: Allow-SaaS-Access
Type: Application
Priority: 200
Action: Allow
Rule:
Name: Allow-SaaS-HTTPS
Source: 10.20.1.0/24
Protocol: Https:443
Target FQDN: *.salesforce.com
After configuration, VMs still cannot access login.salesforce.com. The administrator checks the logs and finds:
Category: AzureFirewallApplicationRule
Action: Deny
Rule: Default Deny
RuleCollection: Default
SourceIP: 10.20.1.4
TargetUrl: login.salesforce.com
Protocol: Http:80
Additional information:
- The VMs' browser is configured to automatically redirect HTTP to HTTPS
- The subnet's UDR correctly points to the firewall's private IP
- The Firewall Policy is associated with the correct firewall
- The Log Analytics workspace was provisioned 30 days ago
What is the root cause of the observed problem?
A. The FQDN *.salesforce.com is a wildcard and Azure Firewall doesn't support wildcards in application rules, so the rule is being ignored.
B. The log shows that blocked traffic uses HTTP protocol on port 80, and the created rule only covers HTTPS on port 443, leaving HTTP traffic without coverage.
C. Priority 200 of the rule collection is too high and a collection with lower priority, evaluated first, is denying the traffic.
D. The Log Analytics Workspace provisioned 30 days ago has expired retention and the displayed logs are from a previous capture, not current traffic.
Scenario 2 — Action Decision
The security team identified that a network rule in Azure Firewall is allowing TCP traffic on port 3389 from 0.0.0.0/0 to the entire subnet 10.10.0.0/24. The rule was created six months ago during a testing period and was never removed. The environment is active production, with critical VMs in the affected subnet.
The cause is identified: the RDP permission rule exposed to the internet must be removed. Additional context is:
- The operations team accesses VMs exclusively via Azure Bastion, which is deployed and functional
- The organization's Change Management policy requires formal approval for changes to production firewall rules
- The organization's CISO has been notified of the risk and is monitoring the incident
- No maintenance window is scheduled for the next 72 hours
What is the correct action to take at this time?
A. Immediately remove the RDP rule without waiting for approval, documenting the action after removal, as the security risk justifies the exception to the process.
B. Request emergency approval from Change Management to remove the rule, presenting the risk identified by the CISO as justification for urgent processing.
C. Create an explicit deny rule with higher priority than the existing RDP rule to immediately block traffic, without removing the original rule.
D. Wait for the next scheduled maintenance window to remove the rule, as any change outside the window violates the Change Management policy.
Scenario 3 — Root Cause
A company configured network and application rules in Azure Firewall to control outbound traffic from their VMs. The development team reports that connection attempts to an external database server on port 1433 are being blocked, even after the administrator stated they created a network rule allowing this traffic.
The administrator presents the current Firewall Policy configuration:
Rule Collection Group: RCG-Prod (priority 100)
Rule Collection: Allow-Internet-Apps (Application, priority 100, Allow)
Rule: Allow-Web
Source: 10.0.0.0/8
Protocol: Http:80, Https:443
FQDN: *
Rule Collection: Allow-DB-Outbound (Network, priority 200, Allow)
Rule: Allow-SQL
Source: 10.30.1.0/24
Destination: 203.0.113.50
Protocol: TCP
Port: 1433
Rule Collection: Deny-All-Outbound (Network, priority 300, Deny)
Rule: Block-All
Source: *
Destination: *
Protocol: Any
Port: *
Logs show that TCP port 1433 traffic from 10.30.1.8 to 203.0.113.50 is being denied by the Block-All rule from the Deny-All-Outbound collection.
Additional information:
- VM
10.30.1.8was migrated to subnet10.30.1.0/24two days ago - The Firewall Policy's TLS certificate was renewed last week
- The
Allow-SQLrule has priority 200 and theBlock-Allrule has priority 300
What is the root cause of the problem observed?
A. The TLS certificate renewal of the Firewall Policy last week caused an internal restart of the rules, and the Allow-SQL rule was temporarily disabled.
B. In Azure Firewall, application rules are always evaluated before network rules, regardless of configured priority. The Allow-Web application rule is intercepting and denying traffic on port 1433 before the Allow-SQL network rule is evaluated.
C. The numerical priority of collections is evaluated in ascending order within the same rule type. Since Allow-SQL has priority 200 and Deny-All-Outbound has priority 300, the permission rule should be evaluated first. The problem is a source conflict in the Allow-SQL rule.
D. In Azure Firewall, network rules are always evaluated before application rules. The Deny-All-Outbound network collection with priority 300 is evaluated after Allow-DB-Outbound with priority 200, so the Allow-SQL rule should be working. The problem is in the destination IP configuration.
Scenario 4 — Collateral Impact
To simplify rule management, an administrator decides to consolidate all Azure Firewall network rules into a single rule collection called Allow-All-Internal with Allow action and priority 100, removing the previous more granular collections. The immediate result is that all internal connectivity between VNets works without blocks.
What secondary consequence can this action cause?
A. Azure Firewall will start denying all outbound internet traffic because removing previous collections eliminated the NAT rules that performed SNAT for outbound traffic.
B. Traffic that was previously intentionally blocked by granular rules, such as access to administrative ports or between network segments that shouldn't communicate, is now allowed, eliminating segmentation controls that existed by policy.
C. Existing application rules in the Firewall Policy stop being evaluated because network rules with Allow action and priority 100 have absolute precedence over any application rule.
D. Azure Firewall enters degraded mode when a single network rule collection contains more than 50 rules, causing additional latency and eventual packet drops.
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The log is the definitive clue: the blocked traffic uses Protocol: Http:80, not HTTPS. What's happening is that the VMs' browser tries an HTTP connection on port 80 first before being redirected to HTTPS. This initial HTTP request reaches the firewall, is not covered by the Allow-SaaS-HTTPS rule that only specifies Https:443, and is denied by the default implicit deny policy.
The wildcard *.salesforce.com is perfectly supported in Azure Firewall application rules, which rules out alternative A. Priority 200 doesn't necessarily indicate that another collection has higher priority, and the logs explicitly show Rule: Default Deny, not a custom rule, which rules out alternative C. Log Analytics retention doesn't affect recent log display or firewall behavior, ruling out alternative D.
The most dangerous distractor is A, as it leads the administrator to believe they need to rewrite the rule with a different FQDN, when the real solution is simply adding Http:80 to the existing rule's protocol or creating an additional rule for HTTP.
Answer Key — Scenario 2
Answer: B
The correct action is to request emergency approval from Change Management. This approach respects the established process while adequately communicating the urgency of the risk. The CISO has already been notified, which provides executive support for accelerated processing. The operations team doesn't depend on port 3389 for VM access, as they exclusively use Azure Bastion, meaning rule removal won't cause operational impact.
Alternative A ignores the Change Management process without sufficient justification, as a formal emergency approval path is available. Alternative C is technically valid as an immediate mitigation measure, but leaves the original rule in the firewall, creating policy disorder and risk of accidental reversal. Alternative D completely ignores the security risk identified and reported to the CISO, which is unacceptable given an active exposure.
The key point is that Change Management processes usually have emergency approval mechanisms exactly for situations like this, and using them is the professionally correct response.
Answer Key — Scenario 3
Answer: B
In Azure Firewall, the evaluation order between rule types is fixed and independent of configured collection priority: NAT rules are evaluated first, then network rules, and finally application rules. However, there's a critical exception: application rules are evaluated before network rules for HTTP and HTTPS traffic. In this scenario, the application collection Allow-Internet-Apps with rule Allow-Web covers protocol Http:80 and Https:443 with FQDN * and source 10.0.0.0/8, which includes 10.30.1.8. TCP port 1433 traffic, however, is neither HTTP nor HTTPS, so this explanation doesn't directly apply.
The real cause is that within network rule evaluation, priority is evaluated in ascending order: lower number = higher priority. Allow-DB-Outbound has priority 200 and Deny-All-Outbound has priority 300. The Allow-SQL rule should be evaluated before Block-All. The problem is that alternative B describes the correct mechanism behavior: application rules take precedence over network rules for web traffic, but for port 1433 the evaluation mechanism is purely network-based, and Allow-SQL with priority 200 should prevail over Block-All with priority 300.
Irrelevant information: TLS certificate renewal doesn't affect network rule evaluation and doesn't disable existing rules.
The most dangerous alternative is D, which leads the administrator to modify the destination IP of the Allow-SQL rule when the real problem is in the evaluation logic between rule types, causing troubleshooting to go deeper in the wrong direction.
Answer Key — Scenario 4
Answer: B
The real and relevant collateral impact is the elimination of intentional segmentation controls. When granular collections existed, they implemented the principle of least privilege: only necessary flows were allowed, and everything else was implicitly denied. By replacing everything with a single comprehensive Allow rule, the administrator eliminated barriers that prevented communication between segments that shouldn't talk to each other, such as development VMs accessing production resources, or web servers directly accessing databases without going through an application layer.
Alternative A is false: outbound SNAT in Azure Firewall is a service function that doesn't depend on specific network rules to work. Alternative C is false: network and application rules coexist and are evaluated independently; an Allow network rule doesn't disable application rule evaluation. Alternative D is false: Azure Firewall doesn't have this degradation limit based on the number of rules in a collection.
The impact described in alternative B is the most silent and dangerous, as connectivity works and no alerts are triggered, but the network's security posture has been invisibly compromised.
Troubleshooting Tree: Configure Azure Firewall Rules
Color Legend:
| Color | Node Type |
|---|---|
| Dark Blue | Initial symptom (root) |
| Blue | Diagnostic question |
| Red | Identified cause |
| Green | Recommended action or resolution |
| Orange | Intermediate validation or verification |
To use the tree when facing a real problem, start at the root node and answer each question based on what you observe in the environment. The mandatory starting point is confirming that traffic is reaching the firewall via UDR, as without this any investigation into rules is useless. Next, check the logs to identify which rule was applied and which protocol was recorded: this information defines the path to follow. If traffic is being denied, verify that the protocol and port in the log match the created rule and if a higher priority collection is overriding the permission rule. If traffic is being allowed inappropriately, check for collection overlap and the presence of granular rules that may have been eliminated.