# Azure Firewall

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/azure-firewall

## Quick definition

Azure Firewall is like a security guard for your cloud network. It checks everything trying to enter or leave your Azure virtual network and blocks anything that isn't allowed. You set the rules, and it automatically enforces them for all your cloud resources.

## Simple meaning

Imagine you own a large office building with many different rooms and offices. You want to make sure that only the right people can enter the building and only the right packages can be sent out. You also want to control which employees can access certain sensitive areas, like the server room or the CEO's office. In the cloud computing world, your virtual network is like that office building. Azure Firewall is like a highly intelligent, always-on security guard posted at the main entrance. This guard doesn't just check badges; it reads the labels on every package, knows the identity of every person, and checks a detailed rulebook you've written. 

 This rulebook (which you create in Azure Firewall) can say things like: 'Allow all web traffic from the marketing department to the internet, but block all traffic from the accounting department to social media sites.' The guard never takes a break, never gets distracted, and follows the rulebook perfectly every time. Unlike a simpler security checkpoint that might just check IP addresses, this guard can inspect the contents of the packages. For example, if a package looks like a regular box of documents but the guard detects it contains a malicious script hidden inside, Azure Firewall can block that package. This deep inspection of traffic is a key feature that makes it much more powerful than a basic filter. 

 In technical terms, you create 'firewall rules' that define which types of network traffic are allowed. These rules can be based on source IP address, destination IP address, destination port (like port 80 for web traffic), and protocol (like TCP or UDP). You can also create Fully Qualified Domain Name (FQDN) rules to allow or block traffic to specific websites. For example, you can allow all users to go to '*.microsoft.com' but block access to 'known-bad-site.com'. Azure Firewall is a 'stateful' firewall, which means it remembers the state of a connection. If a computer inside your network sends a request to a web server, the firewall knows that the response from that web server is part of an allowed conversation and lets it back in, even if your inbound rules are very strict. This makes managing complex traffic flows much easier and more secure.

## Technical definition

Azure Firewall is a managed, cloud-based network security service that protects your Azure Virtual Network resources. It is a fully stateful firewall as a service with built-in high availability and unrestricted cloud scalability. You can centrally create, enforce, and log application and network connectivity policies across subscriptions and virtual networks. 

 Azure Firewall uses a static public IP address for your virtual network resources, allowing outside firewalls to identify traffic originating from your virtual network. The service is integrated with Azure Monitor for logging and analytics. The underlying infrastructure is fully managed by Microsoft, which means you do not have to worry about hardware maintenance, OS patching, or scaling. 

 From a protocol perspective, Azure Firewall supports the inspection of both TCP and UDP packets. It can perform Layer 3 (network layer) filtering based on source and destination IP addresses and ports. More importantly, it provides Layer 4 (transport layer) and Layer 7 (application layer) filtering. Layer 7 filtering is achieved through Application Rules, which allow you to define Fully Qualified Domain Name (FQDN) tags and FQDNs. This allows you to target specific web traffic, such as allowing only Azure services or known-office.com, while blocking everything else. 

 The key components of Azure Firewall include: the firewall itself as a resource in your subscription; a Firewall Policy resource that defines the rules for multiple firewalls; Network Rules (for Layer 3/4 filtering based on IP, port, protocol); Application Rules (for Layer 7 filtering based on FQDNs); NAT Rules (for Destination Network Address Translation, allowing inbound traffic to be forwarded to specific resources); and Threat Intelligence-based filtering, which can alert and block traffic from known malicious IPs and domains. The firewall also supports DNS proxy, allowing it to intercept and process DNS queries from virtual machines for better logging and control. 

 In a real implementation, you typically deploy Azure Firewall into a dedicated subnet within your virtual network, often called 'AzureFirewallSubnet'. This subnet must have a /26 or larger address space. The firewall is then assigned a public and a private IP address. You then route all outbound traffic from your application subnets to this firewall using a custom User-Defined Route (UDR). This forces all internet-bound traffic through the firewall for inspection. Similarly, you can use the firewall to filter inbound traffic by using DNAT rules to expose specific services (like a web server) securely to the internet. 

 Azure Firewall is exam relevant for Microsoft certifications like AZ-104 (Microsoft Azure Administrator) and AZ-305 (Designing Microsoft Azure Infrastructure Solutions). The exams focus on when to deploy Azure Firewall versus a Network Security Group (NSG), how to configure routing to force traffic through the firewall, and how to create and order rules within a Firewall Policy. Understanding the difference between NSG (a basic distributed firewall) and Azure Firewall (a centralized, fully stateful, application-aware firewall) is a frequent exam topic. Candidates must also understand that Azure Firewall is a regional service, meaning it operates within a specific Azure region, and that you need a firewall per region for full coverage.

## Real-life example

Think of Azure Firewall as the security team for a high-tech corporate headquarters. The building (your virtual network) has many departments (subnets), including research and development, finance, human resources, and marketing. The security team isn't just a person at the front desk. It's a sophisticated setup with multiple layers. 

 First, there's a main lobby entrance with a security guard who checks IDs (the public IP address). This guard can stop anyone who is not on the approved visitor list (block IP addresses). But this guard is also very observant. If a visitor says they are from a package delivery service but is carrying a suspicious device, the guard can stop them for a more detailed inspection (deep packet inspection). This is the 'Application Rule' part of the firewall. 

 Next, inside the building, there are internal doors that require a special badge to enter certain floors (NAT rules and DNAT). For example, the finance department may be on a floor that requires a specific badge scan to enter. The security team can set this up so that an external visitor, after being ID-checked at the main lobby, is 'translated' into an internal visitor badge and allowed to go directly to the finance floor (this is Destination Network Address Translation or DNAT). 

 The security team also monitors all outgoing packages (outbound traffic). For instance, the HR department might be allowed to send packages to the government for paperwork (allowed outbound traffic to specific FQDNs), but they are not allowed to send packages to social media sites. The marketing team, on the other hand, might have full access to the internet for advertising. The security team has a huge black-and-white list (threat intelligence) of known malicious actors. If any department tries to send a package to an address on that blacklist, it is immediately stopped and an alert is sent to the IT manager (logging and alerts). 

 Finally, the security team doesn't sleep, doesn't get sick, and never takes a vacation (high availability). If one security guard has to go home (a backend server fails), another guard instantly steps in without anyone even noticing. This is the built-in high availability of Azure Firewall. The entire system is centrally managed by the Chief Security Officer (your cloud administrator) from one console, making it easy to enforce company-wide policies.

## Why it matters

In any IT environment, controlling network traffic is fundamental to security. On-premises, a physical firewall appliance sits at the network perimeter. In the cloud, the concept of a 'perimeter' is more fluid because your resources are virtual and can be spread across multiple regions. Azure Firewall provides a single, central point of control for all traffic entering and leaving your Azure virtual networks. Without it, you would have to rely on individual, less capable security rules on each virtual machine or subnet (Network Security Groups), which is like having every employee lock their own desk drawer but having no security at the building's main entrance. It is unmanageable and insecure at scale. 

 For IT professionals, Azure Firewall enables granular control. You can build rules that allow specific applications (like Office 365) while blocking games or peer-to-peer file sharing. This is critical for compliance with regulations like HIPAA or GDPR, where you must prove you are preventing data exfiltration. The firewall's integration with Azure Monitor means you can log all allowed and denied traffic for forensic analysis. If a security incident occurs, you can trace which traffic was blocked and which was allowed. 

 Another major reason it matters is cost and management overhead. Managing a physical firewall in the cloud is complex and expensive. You would have to spin up a virtual machine, install firewall software, manage OS patches, and handle scaling. Azure Firewall is a managed service. Microsoft handles the infrastructure, patching, and scaling. You just define the policies. This saves significant administrative effort and reduces the chance of misconfiguration. For any organization adopting Azure, understanding and correctly implementing Azure Firewall is not optional; it is a core component of a defense-in-depth security strategy.

## Why it matters in exams

Azure Firewall is a high-weight topic in several Microsoft exams, most notably the AZ-104 (Microsoft Azure Administrator) and the AZ-305 (Azure Solutions Architect Expert). For the AZ-104, you must understand the difference between Azure Firewall and Network Security Groups (NSGs). A common question forces you to decide which service to use in a given scenario. For example, the question might describe a requirement to filter traffic based on a specific application's URL, like blocking access to 'facebook.com' from a specific subnet. An NSG cannot do application-layer filtering; only an Azure Firewall with an Application Rule can. 

 In the AZ-305 exam, the focus shifts to architecture. You need to know how to design a network security solution that uses Azure Firewall in a hub-and-spoke topology. You might be asked to recommend a solution to secure outbound traffic from multiple spoke virtual networks. The correct answer is to deploy Azure Firewall in the hub and route traffic from the spokes to the hub. 

 The SC-900 (Microsoft Security, Compliance, and Identity Fundamentals) covers Azure Firewall more conceptually. You might get a question asking for the primary purpose of Azure Firewall, with answer choices like 'filtering traffic between virtual networks' or 'filtering traffic between a virtual network and the internet'. The correct answer is the latter – while it does filter between networks, its primary use case is internet-bound traffic. 

 Another exam trap is understanding the relationship between Azure Firewall and Azure Firewall Manager. Azure Firewall Manager is a management tool that lets you apply Firewall Policies across multiple firewalls in different subscriptions. The exam expects you to know that Azure Firewall Manager is for large-scale, centralized policy management. 

 For the CompTIA Security+ and other non-Microsoft cloud exams, Azure Firewall is often used as an example of a cloud-native PaaS firewall. Questions might compare it to AWS Network Firewall or Google Cloud Armor. The key point is that it is a managed service with high availability and scalability, unlike deploying a virtual appliance of a third-party firewall. Candidates should know that Azure Firewall is charged based on a combination of deployment hours and data processing, which is different from the predictable cost of a virtual appliance.

## How it appears in exam questions

Questions about Azure Firewall typically fall into several patterns. The first pattern is 'Scenario and Service Selection.' The exam presents a business requirement and asks you to choose the appropriate service. For example, 'A company needs to filter outbound traffic from a virtual network based on the destination URL. The solution must be fully managed and provide high availability. What should you use?' The correct answer is Azure Firewall. The distractors might include Network Security Group (which cannot filter by URL), Azure Application Gateway (which is a load balancer for web traffic), or a third-party firewall VM (which is not fully managed). 

 The second pattern is 'Configuration and Rule Ordering.' These questions ask about the rule processing logic. Azure Firewall evaluates rules in a specific order: DNAT rules, then Network rules, then Application rules. A typical question might present a scenario where traffic is unexpectedly allowed or denied, and you must identify the rule order as the cause. For instance, a destination NAT rule that forwards traffic to an internal server might be allowing malicious traffic because a deny network rule is not being checked first. 

 The third pattern is 'Troubleshooting Connectivity.' A scenario is given where a virtual machine cannot access the internet, even though you have configured outbound rules. The answer often involves the User-Defined Route (UDR). You must remember that simply deploying Azure Firewall and configuring rules is not enough; you must also create a route in the subnet's route table with a next hop of the firewall's private IP address. Without this route, traffic bypasses the firewall. 

 The fourth pattern is 'Cost and Performance.' A question might present a scenario with high data processing costs and ask for a solution. The answer might be to use Azure Firewall in Forced Tunneling mode, which sends internet-bound traffic to an on-premises location for inspection, potentially reducing costs if you have a cheaper on-prem security appliance. 

 A final pattern is 'Hybrid Connection.' Questions about connecting Azure Firewall to an on-premises network, often using VPN Gateway or ExpressRoute. The correct configuration involves ensuring that traffic from on-premises routes through the Azure Firewall rather than directly to Azure services.

## Example scenario

Contoso Ltd. is a company that has migrated its internal web application to Azure. The application runs on a virtual machine in a subnet called 'AppSubnet'. Contoso wants to ensure that only users from their corporate network can access the application. They also want to prevent the virtual machine from being used to access malicious websites. 

 To achieve this, they deploy an Azure Firewall into a dedicated subnet called 'AzureFirewallSubnet'. They create a Network Rule to allow inbound traffic from the corporate network's public IP address (e.g., 203.0.113.0/24) to the application's public IP on port 443 (HTTPS). They also create a DNAT rule to translate the firewall's public IP and port 443 to the private IP of the application VM on port 443. 

 For outbound traffic, they create an Application Rule that allows the VM to only access '*.windowsupdate.com' and '*.microsoft.com' for patching and licensing. All other outbound internet access is denied by default. They configure a User-Defined Route on 'AppSubnet' with a route for 0.0.0.0/0 (all internet traffic) with a next hop of the Azure Firewall's private IP address. 

 When a user from the corporate network tries to access the application, the traffic hits the firewall's public IP, the DNAT rule forwards it to the VM, and the connection is established. If the VM tries to download a file from a malicious site, the Application Rule blocks it because it is not in the allowed FQDN list. This simple scenario demonstrates the core uses of Azure Firewall: secure inbound access via DNAT and controlled outbound access via Application Rules.

## Common mistakes

- **Mistake:** Thinking Azure Firewall works automatically after deployment without configuring routing.
  - Why it is wrong: Azure Firewall inspects traffic only if the traffic is sent to it. By default, subnets have a route to the internet via Azure's default gateway, bypassing the firewall. You must explicitly create a User-Defined Route (UDR) in the subnet's route table with a next hop of the firewall's private IP to force traffic through it.
  - Fix: After deploying Azure Firewall, immediately create a route table for each subnet you want to protect. Add a route for 0.0.0.0/0 with the next hop set to the private IP address of your Azure Firewall.
- **Mistake:** Using a Network Security Group (NSG) instead of Azure Firewall for application-layer filtering (e.g., blocking websites by URL).
  - Why it is wrong: Network Security Groups operate at Layer 3 and Layer 4 of the OSI model. They can filter based on IP addresses, ports, and protocols, but they cannot inspect the contents of packets or look at the URL or FQDN of a web request. Azure Firewall with Application Rules offers Layer 7 inspection for this purpose.
  - Fix: If you need to block or allow traffic based on a website address (FQDN), you must use Azure Firewall and create Application Rules, not Network Security Groups.
- **Mistake:** Assuming Azure Firewall can filter traffic between two virtual networks automatically.
  - Why it is wrong: While Azure Firewall can filter traffic between virtual networks (VNet-to-VNet), it is not the default. It requires explicit configuration, such as peering the VNets and routing traffic through the firewall. Many assume it does this by default, but its primary designed use is for internet-bound traffic. For VNet-to-VNet, you often use peering directly, or route through the firewall only if you need centralized inspection.
  - Fix: For VNet-to-VNet traffic, use VNet peering for default connectivity. Only route traffic through Azure Firewall if you want to inspect or enforce policies between the VNets. This adds cost and latency.
- **Mistake:** Confusing Azure Firewall with Azure Web Application Firewall (WAF) on Application Gateway.
  - Why it is wrong: Azure Firewall is a general-purpose network firewall that filters all traffic (any protocol). Azure WAF is a specialized service that protects web applications from HTTP-specific attacks like SQL injection and cross-site scripting. They serve different purposes and are often used together, but they are not interchangeable.
  - Fix: Use Azure Firewall for general network filtering (IP, port, protocol, FQDN). Use Azure WAF when you need to protect a web application from application-layer attacks.
- **Mistake:** Forgetting that Azure Firewall is a regional service and does not span regions.
  - Why it is wrong: If you have resources in two different Azure regions (e.g., East US and West Europe), one Azure Firewall cannot protect both. Each region requires its own Azure Firewall instance. Learners often think they can deploy one firewall and use it to filter traffic for resources in any region.
  - Fix: Deploy an Azure Firewall in each region where you have resources that require perimeter protection. Use Azure Firewall Manager to manage policies centrally across multiple regions.

## Exam trap

{"trap":"A question asks you to choose a solution to filter outbound traffic from a virtual machine that uses an 'Allow' list of web URLs. The options include Azure Firewall, Network Security Group (NSG), and a third-party firewall appliance. The trap is that you might see 'Network Security Group' and think it can filter by URL because it has 'security' in the name.","why_learners_choose_it":"NSGs are more familiar and easier to set up without additional cost. A learner who hasn't memorized the capabilities of each service might mistakenly believe that NSGs can perform Layer 7 inspection based on URL, because they think of them as a 'firewall' for the subnet. The question might also be phrased to make the NSG seem sufficient.","how_to_avoid_it":"Remember the OSI model. NSGs work at Layers 3 and 4. URL filtering requires Layer 7. Only Azure Firewall (with Application Rules) provides Layer 7 URL filtering natively as a managed service in Azure. If the scenario mentions 'website addresses' or 'FQDNs', the answer must be Azure Firewall."}

## Commonly confused with

- **Azure Firewall vs Network Security Group (NSG):** An NSG is a distributed, stateful firewall that filters traffic at the subnet or network interface level. It works at Layers 3 and 4 (IP, port, protocol). Azure Firewall is a centralized, fully stateful firewall that works at Layers 3, 4, and 7. NSGs cannot filter by URL or FQDN; Azure Firewall can. Azure Firewall also provides centralized logging and threat intelligence, which NSGs do not. (Example: If you need to block port 22 (SSH) to a subnet, use an NSG. If you need to block access to 'facebook.com', use Azure Firewall.)
- **Azure Firewall vs Azure Application Gateway (with WAF):** Application Gateway is a Layer 7 load balancer for HTTP/HTTPS traffic. It can be combined with a Web Application Firewall (WAF) to protect against web exploits like SQL injection. Azure Firewall is a general-purpose firewall that handles any protocol (TCP, UDP, HTTP, etc.) and is not specifically designed for load balancing. They are complementary: you can place Application Gateway behind Azure Firewall to load balance and protect web traffic. (Example: Use Application Gateway to distribute incoming web requests to multiple servers. Use Azure Firewall to block a specific IP address from accessing your entire network, regardless of the application.)
- **Azure Firewall vs Azure Firewall Manager:** Azure Firewall Manager is not a firewall itself; it is a management service that allows you to centrally create, configure, and enforce firewall policies across multiple Azure Firewall instances. Think of Azure Firewall as the security guard, and Azure Firewall Manager as the security company's central command center that sets the rules for all guards. (Example: To apply the same 'Block Social Media' policy to firewalls in East US and West Europe, use Azure Firewall Manager to create the policy and assign it to both firewalls.)
- **Azure Firewall vs Azure Virtual Network NAT Gateway:** A NAT Gateway provides outbound internet connectivity for virtual machines by translating their private IPs to a public IP. It is purely a connectivity service, not a security filter. It does not block traffic; it only allows it. Azure Firewall can also perform NAT but can additionally inspect and block traffic. Use a NAT Gateway when you just need VMs to reach the internet without any filtering. Use Azure Firewall when you need to control and log what leaves your network. (Example: Use NAT Gateway for a development environment where all outbound access is allowed. Use Azure Firewall for production to enforce strict internet access policies.)
- **Azure Firewall vs Azure DDoS Protection:** Azure DDoS Protection is a service that protects against distributed denial-of-service attacks that attempt to overwhelm your network. It operates at the network layer, automatically mitigating volumetric attacks. Azure Firewall can help with some DoS attacks by filtering malicious traffic, but its primary purpose is policy enforcement, not DDoS mitigation. DDoS Protection is an additional service you buy on top of Azure Firewall. (Example: If your web application is under a massive flood of traffic, DDoS Protection will automatically absorb the attack. Azure Firewall will continue to enforce rules (e.g., allow port 443 only) during the attack.)

## Step-by-step breakdown

1. **Create a Resource Group** — First, you need a resource group to logically organize your Azure Firewall and related resources (like virtual network, public IP, and route tables). This helps in managing permissions and costs.
2. **Create a Virtual Network and Subnets** — You must have a virtual network. Crucially, you need a dedicated subnet named 'AzureFirewallSubnet' with a /26 or larger address mask (e.g., 10.0.1.0/26). This subnet is reserved for Azure Firewall and cannot be used for any other resources.
3. **Create a Public IP Address** — Azure Firewall needs a public IP address for outbound traffic and for inbound DNAT rules. This IP will be used as the source IP for traffic leaving your virtual network and as the destination IP for inbound connections. It must be a Standard SKU Public IP.
4. **Deploy Azure Firewall** — In the portal, navigate to 'Create a resource', search for 'Firewall', and select Azure Firewall. You then specify the resource group, name, region, virtual network, 'AzureFirewallSubnet', and the public IP address you created. The deployment will take a few minutes.
5. **Create Firewall Rules** — Once deployed, you create policies or rules directly on the firewall. You define Network Rules (IP/port/protocol), Application Rules (FQDN allow lists), and NAT Rules (inbound DNAT). Rules are evaluated in order (NAT first, then Network, then Application).
6. **Create a Route Table and User-Defined Routes** — This is a critical step. You must create a route table. Add a route with the address prefix '0.0.0.0/0' (all internet traffic) and set the next hop type to 'Virtual appliance' and the next hop address to the private IP of your Azure Firewall. This forces all outbound traffic from that subnet to go through the firewall.
7. **Associate the Route Table with Subnets** — Associate the route table you created with the application subnets (e.g., the subnet where your web servers are). Do not associate it with the 'AzureFirewallSubnet'. After association, traffic from those subnets will start being routed through the firewall.
8. **Test and Monitor Connectivity** — After the route is in place, test outbound internet access from a virtual machine in the protected subnet. Verify that allowed sites work and denied sites are blocked. Use Azure Monitor to view firewall logs and check for denied requests. This helps you validate your rule configuration.

## Practical mini-lesson

In a real-world Azure environment, configuring Azure Firewall is rarely a one-person job or a one-time event. It involves collaboration between network engineers, security teams, and application owners. The first practical step beyond the base deployment is understanding the Firewall Policy model. Using a Firewall Policy, rather than classic rules on the firewall resource itself, is the modern best practice. A Firewall Policy is a separate Azure resource that contains all the rule collections (Network, Application, DNAT, Threat Intelligence). This policy can then be attached to one or more Azure Firewalls. This decoupling allows you to have a 'production' policy and a 'test' policy, and apply them to the appropriate firewalls. 

 Configuration often goes wrong in the area of rule collection priority. Azure Firewall evaluates rule collections in order of their priority number (lower number = higher priority). Within a rule collection, rules are also evaluated in the order they are listed. A common mistake is to create a deny-all rule at a high priority (e.g., priority 100) and then an allow rule for a specific site at a lower priority (e.g., priority 200). The deny-all rule will block everything, including the traffic you want to allow. Always place specific allow rules at a higher priority (lower number) than generic deny rules. 

 Another practical consideration is the use of FQDN tags. Azure Firewall includes built-in FQDN tags like 'AzureWindowsUpdate' and 'AzureBackup'. These tags represent a set of Microsoft-managed FQDNs required for those services. Instead of manually creating Application Rules for every Windows Update URL, you can simply add the 'AzureWindowsUpdate' FQDN tag to your Application Rule collection. This simplifies management and ensures you are not missing any required endpoints as Microsoft updates them. 

 Troubleshooting is a big part of the practical experience. When a user says 'I can't access the internet,' you check the following: first, confirm the UDR is correctly associated with the source VM's subnet. A simple way to test is to log in to the VM and run a network trace or check the effective routes. Second, check the Azure Firewall logs in Azure Monitor. The logs will show 'Allow' or 'Deny' events with the rule that was matched. If the traffic is denied, you see which rule (or lack of a rule) caused the block. Third, ensure the VM's DNS resolution is working. Azure Firewall can act as a DNS proxy; if DNS is not resolving, no web requests will succeed. Fourth, check if the issue is specific to a protocol. For example, if you only allow TCP, UDP-based applications (like DNS lookups) will fail unless you add a UDP rule. 

 Performance monitoring is also key. Azure Firewall has different SKUs (Standard and Premium) with different throughput limits. The Premium SKU adds TLS inspection (decrypting HTTPS traffic), which is compute-intensive. If you are experiencing latency, you might need to scale out by deploying multiple firewalls or migrating to a Premium SKU. Professionals must monitor CPU utilization and throughput in Azure Monitor and set alerts to notify when thresholds are approaching limits.

## Commands

```
az network firewall create --name MyFirewall --resource-group MyRG --location eastus
```
Creates a new Azure Firewall in a specified resource group and location.

*Exam note: Tests understanding of basic firewall provisioning and the required resource group, name, and location parameters.*

```
az network firewall policy create --name MyPolicy --resource-group MyRG
```
Creates a firewall policy that centralizes rule management for Azure Firewall instances.

*Exam note: Exams focus on the distinction between classic rules and policy-based firewalls, and how policy is linked to a firewall.*

```
az network firewall policy rule-collection-group add-filter-collection --policy-name MyPolicy --resource-group MyRG --name AllowSSH --priority 200 --action Allow --rule-type NetworkRule --rule-name AllowSSH --source-addresses 10.0.0.0/24 --protocols TCP --destination-addresses 192.168.1.0/24 --destination-ports 22
```
Adds a network rule collection to a firewall policy to allow SSH traffic from a specific subnet.

*Exam note: Tests ability to configure network rules with source, destination, protocol, and port, a frequent exam scenario for controlling traffic.*

```
az network firewall application-rule create --firewall-name MyFirewall --resource-group MyRG --collection-name AppCollection --action Allow --priority 300 --name AllowHTTP --source-addresses 10.0.0.0/24 --protocols http=80 https=443 --target-fqdns www.contoso.com
```
Creates an application rule to allow outbound HTTP/HTTPS traffic to specific FQDNs.

*Exam note: Exams test understanding of application rules vs. network rules, and how FQDNs are used for outbound filtering.*

```
az network firewall nat-rule create --firewall-name MyFirewall --resource-group MyRG --collection-name DNATCollection --action Dnat --priority 200 --name RDPNat --source-addresses * --protocols TCP --destination-addresses 20.0.0.1 --destination-ports 3389 --translated-address 10.0.0.4 --translated-port 3389
```
Creates a DNAT rule to redirect inbound RDP traffic to an internal virtual machine.

*Exam note: Tests DNAT configuration for inbound access, including translated address and port, common in hybrid networking questions.*

```
az network firewall network-rule create --firewall-name MyFirewall --resource-group MyRG --collection-name NetCollection --action Allow --priority 100 --name AllowDNS --source-addresses 10.0.0.0/16 --protocols UDP --destination-addresses 168.63.129.16 --destination-ports 53
```
Adds a network rule to allow DNS queries to Azure's internal DNS resolver.

*Exam note: Exams emphasize the importance of allowing Azure DNS traffic for proper name resolution, especially in forced tunneling scenarios.*

## Troubleshooting clues

- **Firewall not routing traffic to internal workloads** — symptom: Traffic from the internet to a public IP behind Azure Firewall is dropped or times out.. The firewall is not properly configured with a DNAT rule or the route table (UDR) is missing the default route to the firewall private IP. (Exam clue: Tested as 'Why is inbound traffic not reaching my VM behind Azure Firewall?', answer often points to missing DNAT rule or incorrect UDR.)
- **Outbound internet failure after firewall deployment** — symptom: VMs in a subnet behind Azure Firewall cannot access the internet, even with Allow rules.. The subnet needs a route table with a default route (0.0.0.0/0) pointing to the firewall's private IP, and the firewall must have an outbound rule allowing internet traffic. (Exam clue: Exams test forced tunneling concepts: if the default route is missing or points to the wrong IP, outbound traffic fails.)
- **Application rules not filtering as expected** — symptom: Traffic to allowed FQDNs is blocked, or traffic to blocked FQDNs is permitted.. Application rules require an explicit Allow rule for FQDNs with proper protocol (HTTP/HTTPS). Also, Azure Firewall uses DNS proxy; if DNS resolution fails or is bypassed, rules may not apply. (Exam clue: Exam questions often ask why an application rule is ineffective, with answers related to DNS proxy configuration or rule priority.)
- **Firewall policy not syncing to the firewall instance** — symptom: Changes to the firewall policy are not reflected in the firewall's behavior.. The policy must be associated with the firewall. After updating the policy, it may take a few minutes to propagate. Also, the firewall can be in a 'Failed' provisioning state. (Exam clue: Tests understanding of policy inheritance and propagation delays, a common distractor is 'restart the firewall'.)
- **DNAT rule not translating ports correctly** — symptom: Inbound connections to a non-standard port are not forwarded to the correct internal port.. The DNAT rule must specify both the destination port and the translated port. If they are different, the configuration must be explicit. Also, the destination address must match a public IP of the firewall. (Exam clue: Exams test DNAT with port translation, e.g., 8080 to 80, and ask why the mapping fails.)
- **High latency or dropped packets through the firewall** — symptom: Users report slow connections or intermittent timeouts when passing through the firewall.. Azure Firewall has a throughput limit; burst traffic or too many concurrent connections (SNAT port exhaustion) can cause drops. Also, asymmetric routing can occur if routes are misconfigured. (Exam clue: Exam questions cover SNAT port exhaustion symptoms and solutions like using NAT gateway or increasing firewall SKU.)
- **Firewall logs not showing expected traffic** — symptom: No logs appear in Azure Monitor or Log Analytics for specific traffic flows.. Diagnostic settings must be enabled for the firewall to send logs to a Log Analytics workspace. Also, the rule collection action (Allow/Deny) affects whether logs are generated. (Exam clue: Tested as 'How do you enable logging for Azure Firewall?', answer involves configuring diagnostics and selecting appropriate log categories.)
- **Forced tunneling causing connectivity issues for management traffic** — symptom: After enabling forced tunneling (default route to on-premises), the firewall becomes unresponsive or cannot be managed.. Azure Firewall requires an explicit route to the internet for management IPs (e.g., 23.99.0.0/18). If forced tunneling is enabled without these routes, management traffic fails. (Exam clue: Exams test the requirement for management IP routes in forced tunneling scenarios, a common pitfall.)

## Memory tip

Think 'F.I.R.E.W.A.L.L.' – Force traffic (UDR), Inspect (Application Rules), Route (NAT rules), Enforce (Network Rules), with Always-on high availability, Logging, and Layers 3-7.

## FAQ

**What is the difference between Azure Firewall and a Network Security Group (NSG)?**

An NSG is a basic firewall that filters traffic at the subnet or network interface level based on IP addresses, ports, and protocols (Layers 3 and 4). Azure Firewall is a more advanced, centralized service that can also filter traffic based on application URLs (Layer 7) and provides centralized logging and threat intelligence.

**Do I need both Azure Firewall and an NSG?**

Yes, they are complementary. Azure Firewall acts as the network perimeter guard for all traffic leaving your virtual network. NSGs act as internal security guards between subnets. For example, you might use Azure Firewall to control internet access, and NSGs to prevent the web tier in one subnet from directly accessing the database tier in another subnet.

**Can Azure Firewall block specific websites like Facebook or YouTube?**

Yes. You can create Application Rules in Azure Firewall that block or allow traffic based on Fully Qualified Domain Names (FQDNs). You can create a rule that denies traffic to '*.facebook.com' and '*.youtube.com' while allowing all other traffic.

**How do I force traffic through Azure Firewall?**

You must create a User-Defined Route (UDR) in the subnet's route table. The UDR should have a destination prefix of '0.0.0.0/0' (all internet traffic) and a next hop type of 'Virtual appliance', with the next hop address set to the private IP of your Azure Firewall.

**Is Azure Firewall highly available?**

Yes, Azure Firewall is designed with built-in high availability. The service runs on multiple backend nodes within the same region, so if one node fails, traffic is automatically directed to another, and your public IP remains the same.

**Does Azure Firewall inspect encrypted HTTPS traffic?**

Azure Firewall Standard does not decrypt or inspect HTTPS traffic by default; it can only filter based on the Server Name Indication (SNI) header or the destination IP. Azure Firewall Premium offers TLS inspection, which allows it to decrypt, inspect, and re-encrypt HTTPS traffic to detect threats hidden in encrypted payloads.

**Can I use Azure Firewall to filter traffic between on-premises networks and Azure?**

Yes, you can. You need to connect your on-premises network to Azure via VPN Gateway or ExpressRoute. Then, you configure routing so that traffic from on-premises destined for the internet or other Azure services is directed through Azure Firewall for inspection.

**What is the cost model for Azure Firewall?**

Azure Firewall has a dual cost model. You pay an hourly deployment fee (which varies by SKU and region) and a data processing fee per gigabyte of data that is inspected by the firewall. Costs can add up quickly with high traffic volumes.

## Summary

Azure Firewall is a cornerstone of network security in Microsoft Azure. As a fully managed, stateful firewall as a service, it provides centralized control over inbound and outbound traffic for your virtual networks. Unlike simpler services like Network Security Groups, Azure Firewall can inspect traffic at the application layer (Layer 7), allowing you to create policies based on specific website addresses (FQDNs). It also offers threat intelligence integration, built-in high availability, and seamless integration with Azure Monitor for logging. 

 For IT certification exams, especially the AZ-104 and AZ-305, understanding Azure Firewall is critical. You must know its place in the security ecosystem, how it differs from NSGs and Application Gateways, and the mandatory steps for configuration-especially the User-Defined Route to force traffic through it. Common exam traps include confusing it with other services or forgetting the routing piece. 

 In practice, Azure Firewall simplifies network security management. It allows security teams to define a single set of policies that apply across multiple subscriptions and regions. However, it also requires careful planning to avoid high costs and performance bottlenecks. For any IT professional working with Azure, mastering Azure Firewall is not just about passing an exam; it is about building secure, scalable, and manageable cloud infrastructures.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/azure-firewall