Getting Started with Azure Firewall REST API – Part II
In Part I of this series, we explored how to interact with Azure’s REST APIs using Bruno. We laid the foundation for provisioning and managing Azure Firewall using REST API, covering the core setup tasks such as creating the firewall instance, defining policies, and implementing basic rule configurations. In Part II, we take a step forward by diving into advanced configurations that are crucial for securing complex, large-scale environments. These configurations allow you to fine-tune traffic control, improve security posture, and enhance visibility into network activities. In this part, we’ll cover: Initial setup: Authentication and prerequisites Creating DNAT Rules to expose internal resources securely Enabling IDPS (Intrusion Detection and Prevention System) with Signature Overrides and Bypass Rules Using Web Categories to simplify and strengthen application rule Creating FQDN Filtering Rules to allow or deny traffic based on domain names Creating URL Filtering Rules to allow or deny traffic based on URLs Associating Multiple Public IPs with Azure Firewall for better scalability Enabling Diagnostic Settings for detailed logging and monitoring Customizing SNAT Private IP Address Ranges for precise outbound traffic control By the end of this part, you'll have a deeper understanding of how to leverage Azure Firewall’s full potential to meet real-world enterprise security needs— using REST API. Initial Setup: Authentication and Prerequisites: After downloading and setting up Bruno as the REST API client, creating a new collection as described in Part I, you will do the following: Service Principal Creation: Using Azure CLI, create a Service Principal in the correct subscription as shown below: az ad sp create-for-rbac --name "BrunoClient" --role Contributor --scopes /subscriptions/{subscription-id} Make a note of the following: App ID (client_id) Tenant ID Password (client_secret) Request a Bearer Token: Using BRUNO, get the Bearer Token using the following PUT request and details we derived from the above Service Principal Creation. POST: https://login.microsoft.com/{TenantID}/oauth2/token Body (x-www-form-urlencoded): grant_type: client_credentials client_id: {App ID} client_secret: {Password} resource: https://management.azure.com Add Authorization Header for API Requests: Once you get the Bearer Token, you need to add this to every Request as shown below: We also need to refresh the Bearer Token each time it expires and update it in the Token field for every request. Typically, it expires every 1 hour, however, the exact expiration time can vary depending on the API and its configuration. Get Your Subscription ID: Retrieve the Subscription ID for the Azure subscription where your Azure Firewall instance is deployed Using AZ CLI, get the Subscription ID to be used in the API requests: az account show --query id -o tsv Azure Firewall Configurations via REST API: In Part I of this series, we discussed how to use REST API to configure the Azure Firewall resource and the Firewall Policy. Now, let's delve into the advanced features. Configuring DNAT Rule: This example demonstrates how to configure a DNAT (Destination Network Address Translation) rule using Azure Firewall's REST API. It uses the 'FirewallPolicyNatRuleCollection' type to redirect traffic from a public IP and port to an internal FQDN and port. Request: PUT https://management.azure.com/subscriptions/{SubscriptionID}/resourceGroups/{Resourcegroupname}/providers/Microsoft.Network/firewallPolicies/{FirewallPolicyName}/ruleCollectionGroups/{RuleCollectionName}?api-version=2024-05-01 Request Body: { "properties": { "priority": 100, "ruleCollections": [ { "ruleCollectionType": "FirewallPolicyNatRuleCollection", "priority": 100, "name": "Example-Nat-Rule-Collection", "action": { "type": "DNAT" }, "rules": [ { "ruleType": "NatRule", "name": "nat-rule1", "translatedFqdn": "internalhttp.server.net", "translatedPort": "8080", "ipProtocols": [ "TCP", "UDP" ], "sourceAddresses": [ "2.2.2.2" ], "sourceIpGroups": [], "destinationAddresses": [ "{Firewall IP}" ], "destinationPorts": [ "8080" ] } ] } ] } } When the PUT request is successful, the following rule is created under DNAT Rule Collection Group as shown below: Enabling Intrusion Detection (IDPS): When using Azure Firewall Premium, enabling Intrusion Detection and Prevention (IDPS) helps monitor, detect and respond to suspicious activities, enhancing security. Below is a simple example that shows how to use the PUT method to update your Firewall policy with an IDPS configuration such as enabling it, applying signature overrides and bypassing certain trusted traffic from the IDPS rules. 💡 Note: Make sure your Azure Firewall SKU is Premium, as IDPS is only available in that tier. Request: PUT https://management.azure.com/subscriptions/{SubscriptionID}/resourceGroups//{Resourcegroupname}/providers/Microsoft.Network/firewallPolicies//{FirewallPolicyName}?api-version=2024-05-01 Request Body: { "tags": { "key1": "value1" }, "location": "westus", "properties": { "threatIntelMode": "Alert", "threatIntelWhitelist": { "ipAddresses": [], "fqdns": ["*.microsoft.com"] }, "snat": { "privateRanges": ["IANAPrivateRanges"] }, "sql": { "allowSqlRedirect": true }, "sku": { "tier": "Premium" }, "intrusionDetection": { "mode": "Alert", "configuration": { "signatureOverrides": [ { "id": "2000105", "mode": "Off" } ], "bypassTrafficSettings": [ { "name": "BypassCustomRule1", "protocol": "TCP", "sourceAddresses": ["192.168.1.0/24"], "destinationAddresses": ["10.1.1.4"], "destinationPorts": ["443"] } ] } } } } When the PUT request is successful, IDPS is enabled in Alert mode (you can also set it to Alert & Deny if needed) as shown below. In this example: Signature ID 2000105 is overridden and set to Off, which appears as Disabled in the Azure Portal. A custom bypass rule is configured to exclude specific traffic (based on source IP, destination IP, and port) from IDPS filtering. This configuration provides flexibility to fine-tune your threat detection settings while allowing exception/safe traffic to pass without inspection. Creating Web Categories Rule: Azure Firewall supports filtering outbound web traffic based on web categories, allowing administrators to block or allow access to entire categories of websites (e.g., Social Networking, Gambling, Adult Content). This provides a scalable way to enforce corporate internet usage policies without needing to specify individual domains. 💡 Note: While this feature is available in both Azure Firewall Standard and Premium, the Premium SKU offers more granular control by matching categories based on the entire URL for both HTTP and HTTPS traffic. Below is an example of how to configure a web category-based application rule using REST API: Request: PUT https://management.azure.com/subscriptions/{SubscriptionID}/resourceGroups/{Resourcegroupname}/providers/Microsoft.Network/firewallPolicies/{FirewallPolicyName}/ruleCollectionGroups/{RuleCollectionName}?api-version=2024-05-01 Request Body: Request Body: { "properties": { "priority": 200, "ruleCollections": [ { "name": "WebCategoryRuleCollection1", "ruleCollectionType": "FirewallPolicyFilterRuleCollection", "priority": 200, "action": { "type": "Deny" }, "rules": [ { "ruleType": "ApplicationRule", "name": "blockWebCategories", "description": " Block social networking and travel-related websites", "protocols": [ { "protocolType": "Https", "port": 443 }, { "protocolType": "Http", "port": 80 } ], "sourceAddresses": [ "10.0.0.0/24" ], "webCategories": [ "SocialNetworking", "Travel" ] } ] } ] } } When this PUT request is successful, the rule denies outbound traffic to websites categorized under Social Networking and Travel from the source IP address range 10.0.0.0/24, for both ports 80 & 443 as shown below: Creating FQDN Filtering Rule: In many enterprise scenarios, it’s important to control which websites users can access. Azure Firewall supports FQDN-based application rules that allow you to filter outbound traffic based on fully qualified domain names (FQDNs), such as www.instagram.com or www.expedia.com. These rules work by inspecting the Server Name Indication (SNI) field during the TLS handshake (for HTTPS traffic) or the Host header in HTTP requests. This makes it possible to apply access control without decrypting the full traffic stream — which means FQDN filtering works even without TLS inspection and is supported in both Standard and Premium SKUs. Request: PUT https://management.azure.com/subscriptions/{SubscriptionID}/resourceGroups/{Resourcegroupname}/providers/Microsoft.Network/firewallPolicies/{FirewallPolicyName}/ruleCollectionGroups/{RuleCollectionName}?api-version=2024-05-01 Request Body: { "properties": { "priority": 100, "ruleCollections": [ { "name": "AppRuleCollection1", "ruleCollectionType": "FirewallPolicyFilterRuleCollection", "priority": 100, "action": { "type": "Deny" }, "rules": [ { "ruleType": "ApplicationRule", "name": " blockSpecificFQDNs", "description": " Block specific websites by FQDN", "protocols": [ { "protocolType": "Https", "port": 443 } ], "sourceAddresses": [ "10.0.0.0/24" ], "targetFqdns": [ "www.instagram.com", "www.expedia.com" ] } ] } ] } } Creating URL Filtering Rule: If you want to control not just which domains users can access, but also specific URLs or paths within those domains, you can use the URL filtering capabilities. To enable this, you must turn on TLS inspection. With HTTPS traffic, only the domain name (e.g., example.com) is visible during the TLS handshake via SNI (Server Name Indication). The full URL path (e.g., /downloads/malware.exe) remains encrypted. To inspect it, the firewall must decrypt the traffic, apply your rules, and then re-encrypt it before forwarding it to the destination. This capability gives you granular control for scenarios like: Blocking access to specific file download paths Restricting parts of websites while allowing others Enforcing strict security policies without over blocking 💡 Note: URL path-based filtering is available only in Azure Firewall Premium. 💡 Note: Ensure TLS inspection is enabled for URL filtering to work on HTTPS traffic. Request: PUT https://management.azure.com/subscriptions/{SubscriptionID}/resourceGroups/{Resourcegroupname}/providers/Microsoft.Network/firewallPolicies/{FirewallPolicyName}/ruleCollectionGroups/{ApplicationRuleCollectionName}?api-version=2024-05-01 Request Body: Request Body: { "properties": { "priority": 100, "ruleCollections": [ { "name": "AppRuleCollection1", "ruleCollectionType": "FirewallPolicyFilterRuleCollection", "priority": 100, "action": { "type": "Deny" }, "rules": [ { "ruleType": "ApplicationRule", "name": " blockSpecificURLs", "description": " Block specific websites by FQDN", "protocols": [ { "protocolType": "Https", "port": 443 } ], "sourceAddresses": [ "10.0.0.0/24" ], "terminateTLS": true, "targetUrls": [ "www.example.com/downloads/malware.exe", "www.example.com/blockedpath/"] } ] } ] } } When this PUT request is successful, the following rule will be created to block access to the specified target FQDNs from the 10.0.0.0/24 source IP address range, as shown below: Associating Multiple Public IP’s: When managing Azure Firewall at scale, assigning multiple public IP addresses can help support higher availability and throughput, especially for SNAT or DNAT scenarios. We will walk through how to use the PUT method in Azure Firewall's REST API to deploy and associate multiple IP configurations efficiently. 💡 Note: When configuring multiple public IP addresses, ensure that you use Standard SKU public IP addresses, as Basic SKU public IPs are not supported with Azure Firewall. 💡 Note: Associating multiple public IP addresses with your firewall increases the available SNAT ports, enhancing scalability. Request: PUT https://management.azure.com/subscriptions/{SubscriptionID}/resourceGroups/{ResourceGroup}/providers/Microsoft.Network/azureFirewalls/{FirewallName}?api-version=2023-05-01 Request Body: { "location": "westus", "properties": { "ipConfigurations": [ { "name": "ipConfig1", "properties": { "publicIPAddress": { "id": "/subscriptions/{SubscriptionID}/resourceGroups/{ResourceGroupName}/ providers/Microsoft.Network/publicIPAddresses/{PublicIPName} " }, "subnet": { "id": "/subscriptions/{SubscriptionID}/resourceGroups/{ResourceGroupName}/providers/Microsoft.Network/virtualNetworks/{VnetName}/subnets/{SubnetName}" } } }, { "name": "ipConfig2", "properties": { "publicIPAddress": { "id": "/subscriptions/{SubscriptionID}/resourceGroups/{ResourceGroupName}/ providers/Microsoft.Network/publicIPAddresses/{PublicIPName} " } } } ] } } When this PUT request is successful, the specified public IP addresses will be associated with the Azure Firewall, as shown below: Enable Diagnostic Logging: Using the REST API, you can configure Azure Firewall to capture important log categories such as Application Rules, Network Rules, and DNS Proxy logs, as well as performance metrics and more. 💡 Note: A Log Analytics workspace must be set up beforehand to store the logs generated by the API configuration below. Below is an example of how to set up diagnostic settings by linking the firewall to a Log Analytics workspace: Request: PUT https://management.azure.com/subscriptions/{Subscription ID}/resourceGroups/{ResourceGroupName} /providers/Microsoft.Network/azureFirewalls/{FirewallName} /providers/microsoft.insights/diagnosticSettings/{DiagnosticsSettingsName}?api-version=2021-05-01-preview Request Body: { "properties": { "workspaceId": "/subscriptions/{SubscriptionID}/resourceGroups/{Resourcegroupname}/providers/Microsoft.OperationalInsights/workspaces/FirewallLogs", "logs": [ { "category": "AzureFirewallApplicationRule", "enabled": true, "retentionPolicy": { "enabled": false, "days": 0 } }, { "category": "AzureFirewallNetworkRule", "enabled": true, "retentionPolicy": { "enabled": false, "days": 0 } }, { "category": "AzureFirewallDnsProxy", "enabled": true, "retentionPolicy": { "enabled": false, "days": 0 } } ], "metrics": [ { "category": "AllMetrics", "enabled": true, "retentionPolicy": { "enabled": false, "days": 0 } } ], "logAnalyticsDestinationType": "Dedicated" } } When the PUT request is successful, the following logs and metrics will be enabled, and these logs will be sent to the Log Analytics Workspace specified here: Configuring SNAT Exclusions: Azure Firewall provides SNAT capability for all outbound traffic to public IP addresses. If your organization uses registered IP address ranges outside of IANA RFC 1918 or IANA RFC 6598 for private networks, Azure Firewall SNATs the traffic to one of the firewall's private IP addresses in AzureFirewallSubnet. You can configure Azure Firewall to not SNAT your public IP address range. For example, specify an individual IP address as x.x.x.x or a range of IP addresses as x.x.x.x/24. Below is an example of how to configure SNAT exclusions using REST API: Request PUT https://management.azure.com/subscriptions//{Subscription ID}/resourceGroups//{ResourceGroupName} /providers/Microsoft.Network/firewallPolicies/ {FirewallPolicyName}?api-version=2024-05-01 Request Body: { "tags": { "key1": "value1" }, "location": "westus", "properties": { "threatIntelMode": "Alert", "threatIntelWhitelist": { "ipAddresses": [ ], "fqdns": [ "*.microsoft.com" ] }, "snat": { "privateRanges": [ "1.2.3.4", "5.6.7.8”, "IANAPrivateRanges" ] }, "sql": { "allowSqlRedirect": true }, "sku": { "tier": "Premium" } } } When this PUT request is successful, the following SNAT exclusion is added alongside the default private IP ranges as shown below: Conclusion: In this part of the series, we explored how to take Azure Firewall deployments to the next level by configuring advanced features through the REST API. From setting up DNAT rules and enabling IDPS with fine-grained control, to applying web category-based filtering, FQDN filtering, URL filtering, associating multiple public IP addresses, enabling diagnostic logging, and customizing SNAT behaviors — you now have a comprehensive toolkit to secure complex environments at scale. By using the REST API, you can automate firewall management, enforce consistent security policies, and quickly adapt to changing network requirements — all critical capabilities for modern cloud-native architectures.Optimize Azure Firewall logs with selective logging
A common question from customers is whether Azure Firewall supports filtering or selecting which logs are sent to a Log Analytics workspace. This concern usually stems from the high cost of storing large volumes of data — especially in environments where the firewall inspects substantial amounts of network traffic. Azure Firewall now supports ingestion-time transformation of logs in Azure Log Analytics. This capability introduces selective and advanced filtering, giving customers more control over what data is collected and analyzed. In this blog post, we’ll explore a major new capability: Azure Firewall now supports ingestion-time transformations in Log Analytics — enabling flexible, cost-efficient logging through selective data collection. Why does it matter? For many enterprise customers, the cost of ingesting Azure Firewall logs into Log Analytics — especially at scale — can be significant. Depending on the logging mode (Basic or Analytics), ingestion costs can be substantial, potentially making it challenging to expand logging coverage across additional workloads. With ingestion-time transformations, users can filter logs by rows, columns, timestamps, and more — and apply transformations before ingestion. This ensures that only relevant and critical data is stored, helping reduce costs while retaining the necessary telemetry for analysis, threat detection, and compliance. Customer benefits Security monitoring: Log only suspicious traffic for more targeted threat detection. Cost optimization: Avoid ingesting and storing unnecessary data. Compliance: Use DCR (data collection rules) to filter and route logs to meet audit/reporting needs. Incident response: Focus on logs that matter, accelerating investigation time. Custom alerts: Build insights on top of curated, high-value logs. What are transformations in Azure Monitor? Ingestion-time transformations in Azure Monitor allow you to filter or modify incoming telemetry before it reaches your Log Analytics workspace. This happens in the cloud pipeline — after the data source (such as Azure Firewall) sends its logs, but before those logs are ingested and stored. Transformations are defined using DCR and written in Kusto Query Language (KQL). Each transformation runs against incoming records individually, letting you precisely control what gets stored – and what doesn’t. For example, you might collect only entries where the action column contains the word “deny”. That filter can be applied at ingestion time, so only those critical logs are stored. The diagram below shows how this works end-to-end, from data source to filtered ingestion. To learn more and estimate potential processing charges, refer to the official documentation. Transforming Azure Firewall logging In this section, we’ll walk through a few real-world use cases shared by customers — including how to create a DCR based on specific filtering criteria. Important: Ingestion-time transformations for Azure Firewall logs are supported only when using resource-specific logs. If you’re using legacy diagnostic settings, this capability is not available. To enable transformations, ensure your firewall is configured to send logs using the Azure Firewall resource-specific log schema. First, navigate to your Log Analytics workspace and locate the table where your Azure Firewall logs are stored (e.g., AZFWApplicationRule). Click the three-dot menu (…) on the right and select “Create transformation”. Creating a transformation is a 3 steps-process. Step 1 – Basics: Create a DCR to define how incoming data is processed and specify where it should be stored. Step 2 – Schema and transformation: Use the Transformation Editor to write a KQL query that filters the incoming data based on your criteria. Step 3 – Review: Review the table name, DCR name, and KQL query before clicking “Create”. This summary ensures everything is configured correctly. For more information on how to create a DCR, refer to the official documentation. Use case 1: Excluding alerts from low priority IDPS signatures This DCR transformation filters and reshapes incoming Azure Firewall IDPS logs before they're ingested into a Log Analytics workspace. source | where Action !contains "alert" and Severity != 3 | project TimeGenerated, Protocol, SourceIp, SourcePort, DestinationIp, DestinationPort, Action, SignatureId, Description, Severity Here's a breakdown of what it does: source: This refers to the incoming data stream — in this case, the AZFWIdpsSignature table (intrusion detection/prevention logs from Azure Firewall). | where Action !contains "alert" and Severity != 3: This line filters out any log entries where the Action contains "alert" (non-blocking detection events). Any entries where Severity equals 3 (which represents low severity events). The result: We’re keeping only more actionable or higher-severity entries that don’t just raise alerts but may involve blocks or higher-severity behaviors (e.g., deny actions, critical or warning severities). | project ...: The project statement selects and forwards only the specified columns to the Log Analytics workspace. When you run a query in your Log Analytics workspace, you’ll notice that only the specific columns defined in your transformation’s project statement are available — and they appear in the exact order specified in the query. Use case 2: Filtering out unnecessary logs (trusted or testing networks) This DCR transformation filters out log entries from specific source IP address ranges before they're ingested into Azure Monitor. In this scenario, the 10.0.200.x and 10.0.300.x ranges might represent trusted or test network segments that generate high volumes of traffic — traffic that don’t need to be logged. By excluding these IPs at ingestion time, you can significantly reduce unnecessary log volume and associated costs. source | where not( SourceIp startswith "10.0.200." or SourceIp startswith "10.0.300." ) | project TimeGenerated, Protocol, SourceIp, SourcePort, DestinationIp, DestinationPort, Action, ActionReason, Policy, RuleCollection, Rule Here's a breakdown of what it does: source: This refers to the incoming data stream — in this case, the AZFWNetworkRule table. | where not (…): Applies a filter to exclude logs that match the criteria inside. SourceIp startswith "10.0.200." and SourceIp startswith "10.0.300.": These conditions match any log where the SourceIp address falls within the 10.0.200.0/24 or 10.0.300.0/24 subnets (i.e., IPs like 10.0.200.1, 10.0.200.45, etc.). | project ...: The project statement selects and forwards only the specified columns to the Log Analytics workspace. Conclusion By leveraging ingestion-time transformations through DCR, organizations gain full control over which Azure Firewall logs are ingested in Log Analytics. This selective logging capability helps reduce noise, cut costs, and retain only high-value data for security, compliance, and operational insights. As Azure Firewall evolves these enhancements offer greater flexibility and efficiency for managing cloud-native network telemetry. Resources Azure updates | Microsoft Azure Monitoring data reference for Azure Firewall | Microsoft Learn Transformations Azure Monitor - Azure Monitor | Microsoft Learn Create a transformation in Azure Monitor - Azure Monitor | Microsoft LearnDraft and deploy - Azure Firewall policy changes [Preview]
In today’s cloud-centric digital landscape, maintaining secure and scalable network infrastructure is essential for enterprises navigating dynamic workloads and compliance demands. Azure Firewall, Microsoft’s fully managed, cloud-native service, offers robust security capabilities including stateful packet inspection, advanced threat prevention, autoscaling, and centralized policy enforcement across distributed Azure environments. To further simplify policy administration, the recently introduced draft and deploy feature enables security teams to safely edit firewall policies in a staging environment and apply those changes atomically. This structured workflow supports collaborative review cycles, minimizes configuration risks, and streamlines updates—especially for organizations with formal governance and change-management requirements. Challenges before draft and deploy: Before draft and deploy, firewall policy updates faced several operational hurdles: Every change, however small, can take several minutes to deploy Organizations with strict change-management frameworks struggled to integrate policy updates into existing approval workflows. Direct application of rule changes increases the chance of errors that could block critical traffic or expose workloads. How draft and deploy works: Draft and deploy introduces a two-phase model that decouples editing from deployment: Draft phase Clone the active policy into a temporary draft. Make and review multiple changes—add, modify, or remove rules—without affecting live traffic. Collaborate with peers, assign reviewers, and iterate until the draft meets requirements. Deploy phase Validate the draft to catch unsupported or invalid configurations. Deploy the draft in a single, atomic operation that replaces the active policy. This approach ensures policy consistency, minimizes deploy time, and reduces repetitive deployments. Supported scenarios and limitations: Azure Firewall draft and deploy is currently in preview and designed exclusively for Azure Firewall policies. Key points include: Aspect Details Availability Preview feature for Azure Firewall policy only Supported configurations Standard and Premium SKUs; policies with classic rules are not supported Draft persistence Drafts are snapshots of the applied policy at the time of draft creation; changes to the live policy afterward are not auto reflected Rule collection group (RCG) Creating new RCGs within a draft is not supported; add RCGs directly to the live policy first Concurrent drafts Only one draft per policy at a time Using draft and deploy via the Azure portal: Navigate to your Firewall policy resource. Under “Policy management,” select Draft + Deployment. Click Create draft to clone the current policy. Edit rules and collections as needed, saving frequently. The below image shows that a new network rule named “Microsoft” has been added. After review, select Deploy draft to apply all changes atomically. The rule changes will be highlighted as shown in below image. Once successfully deployed, this process can be repeated to make further updates to your policy as needed. As we can see in the below image the newly added rule has been successfully deployed and is now part of the policy. Azure CLI: The following CLI commands could be used to update the policy draft. More information on CLI commands can be found here: Draft + Deployment CLI Action Command Create a draft az network firewall policy draft create --name <policyName> --resource-group <rgName> List existing draft az network firewall policy draft list --name <policyName> --resource-group <rgName> Update draft az network firewall policy update --name <policyName> --resource-group <rgName> --rules <ruleFile> Deploy the draft az network firewall policy draft deploy --name <policyName> --resource-group <rgName> Delete a draft az network firewall policy draft delete --name <policyName> --resource-group <rgName> Troubleshooting scenarios: Here are some of the common troubleshooting scenarios and their respective causes and resolutions. Scenario Possible cause Resolution No changes in draft after edits Draft was created before policy updates Compare draft timestamp with change log; recreate or manually apply missing edits to the draft Commit validation errors Unsupported or invalid rule types Review draft for nested RCGs or invalid protocols; correct or remove unsupported configurations Draft creation fails Existing draft already present Deploy or delete the existing draft, then retry creation CLI error: “RGCA creation failed” Outdated or misconfigured CLI extension Update extension to v1.2.3 or higher; verify CLI configuration Deployment succeeds but no visible changes Draft missing latest edits Ensure all intended changes are included in the draft before deployment PowerShell/REST API draft creation fails Invalid API parameters Validate request schema against the Azure REST API documentation Conclusion: Draft and deploy transforms Azure Firewall policy management by separating editing from deployment and enabling atomic policy updates. Organizations can now collaborate on complex rule changes, enforce governance, and maintain continuous security without sacrificing agility. References: Azure Firewall Draft + Deployment (preview) | Microsoft Learn az network firewall policy draft | Microsoft LearnAZ-500: Microsoft Azure Security Technologies Study Guide
The AZ-500 certification provides professionals with the skills and knowledge needed to secure Azure infrastructure, services, and data. The exam covers identity and access management, data protection, platform security, and governance in Azure. Learners can prepare for the exam with Microsoft's self-paced curriculum, instructor-led course, and documentation. The certification measures the learner’s knowledge of managing, monitoring, and implementing security for resources in Azure, multi-cloud, and hybrid environments. Azure Firewall, Key Vault, and Azure Active Directory are some of the topics covered in the exam.Combining firewall protection and SD-WAN connectivity in Azure virtual WAN
Virtual WAN (vWAN) introduces new security and connectivity features in Azure, including the ability to operate managed third-party firewalls and SD-WAN virtual appliances, integrated natively within a virtual WAN hub (vhub). This article will discuss updated network designs resulting from these integrations and examine how to combine firewall protection and SD-WAN connectivity when using vWAN. The objective is not to delve into the specifics of the security or SD-WAN connectivity solutions, but to provide an overview of the possibilities. Firewall protection in vWAN In a vWAN environment, the firewall solution is deployed either automatically inside the vhub (Routing Intent) or manually in a transit VNet (VM-series deployment). Routing Intent (managed firewall) Routing Intent refers to the concept of implementing a managed firewall solution within the vhub for internet protection or private traffic protection (VNet-to-VNet, Branch-to-VNet, Branch-to-Branch), or both. The firewall could be either an Azure Firewall or a third-party firewall, deployed within the vhub as Network Virtual Appliances or a SaaS solution. A vhub containing a managed firewall is called a secured hub. For an updated list of Routing Intent supported third-party solutions please refer to the following links: managed NVAs SaaS solution Transit VNet (unmanaged firewall) Another way to provide inspection in vWAN is to manually deploy the firewall solution in a spoke of the vhub and to cascade the actual spokes behind that transit firewall VNet (aka indirect spoke model or tiered-VNet design). In this discussion, the primary reasons for choosing unmanaged deployments are: either the firewall solution lacks an integrated vWAN offer, or it has an integrated offer but falls short in horizontal scalability or specific features compared to the VM-based version. For a detailed analysis on the pros and cons of each design please refer to this article. SD-WAN connectivity in vWAN Similar to the firewall deployment options, there are two main methods for extending an SDWAN overlay into an Azure vWAN environment: a managed deployment within the vhub, or a standard VM-series deployment in a spoke of the vhub. More options here. SD-WAN in vWAN deployment (managed) In this scenario, a pair of virtual SD-WAN appliances are automatically deployed and integrated in the vhub using dynamic routing (BGP) with the vhub router. Deployment and management processes are streamlined as these appliances are seamlessly provisioned in Azure and set up for a simple import into the partner portal (SD-WAN orchestrator). For an updated list of supported SDWAN partners please refer to this link. For more information on SD-WAN in vWAN deployments please refer to this article. VM-series deployment (unmanaged) This solution requires manual deployment of the virtual SD-WAN appliances in a spoke of the vhub. The underlying VMs and the horizontal scaling are managed by the customer. Dynamic route exchange with the vWAN environment is achieved leveraging BGP peering with the vhub. Alternatively, and depending on the complexity of your addressing plan, static routing may also be possible. Firewall protection and SD-WAN in vWAN THE CHALLENGE! Currently, it is only possible to chain managed third-party SD-WAN connectivity with Azure Firewall in the same vhub, or to use dual-role SD-WAN connectivity and security appliances. Routing Intent provided by third-party firewalls combined with another managed SD-WAN solution inside the same vhub is not yet supported. But how can firewall protection and SD-WAN connectivity be integrated together within vWAN? Solution 1: Routing Intent with Azure Firewall and managed SD-WAN (same vhub) Firewall solution: managed. SD-WAN solution: managed. This design is only compatible with Routing Intent using Azure Firewall, as it is the sole firewall solution that can be combined with a managed SD-WAN in vWAN deployment in that same vhub. With the private traffic protection policy enabled in Routing Intent, all East-West flows (VNet-to-VNet, Branch-to-VNet, Branch-to-Branch) are inspected. Solution 2: Routing Intent with a third-party firewall and managed SD-WAN (2 vhubs) Firewall solution: managed. SD-WAN solution: managed. To have both a third-party firewall managed solution in vWAN and an SD-WAN managed solution in vWAN in the same region, the only option is to have a vhub dedicated to the security solution deployment and another vhub dedicated to the SD-WAN solution deployment. In each region, spoke VNets are connected to the secured vhub, while SD-WAN branches are connected to the vhub containing the SD-WAN deployment. In this design, Routing Intent private traffic protection provides VNet-to-VNet and Branch-to-VNet inspection. However, Branch-to-Branch traffic will not be inspected. Solution 3: Routing Intent and SD-WAN spoke VNet (same vhub) Firewall solution: managed. SD-WAN solution: unmanaged. This design is compatible with any Routing Intent supported firewall solution (Azure Firewall or third-party) and with any SD-WAN solution. With Routing Intent private traffic protection enabled, all East-West flows (VNet-to-VNet, Branch-to-VNet, Branch-to-Branch) are inspected. Solution 4: Transit firewall VNet and managed SDWAN (same vhub) Firewall solution: unmanaged. SD-WAN solution: managed. This design utilizes the indirect spoke model, enabling the deployment of managed SD-WAN in vWAN appliances. This design provides VNet-to-VNet and Branch-to-VNet inspection. But because the firewall solution is not hosted in the hub, Branch-to-Branch traffic will not be inspected. Solution 5 - Transit firewall VNet and SD-WAN spoke VNet (same vhub) Firewall solution: unmanaged. SD-WAN solution: unmanaged. This design integrates both the security and the SD-WAN connectivity as unmanaged solutions, placing the responsibility for deploying and managing the firewall and the SD-WAN hub on the customer. Just like in solution #4, only VNet-to-VNet and Branch-to-VNet traffic is inspected. Conclusion Although it is currently not possible to combine a managed third-party firewall solution with a managed SDWAN deployment within the same vhub, numerous design options are still available to meet various needs, whether managed or unmanaged approaches are preferred.Using Azure Firewall as a Gateway for All Outbound Traffic to the Internet
Hey everyone! I just uploaded a new guide on GitHub where I walk through setting up Azure Firewall in a classic Hub & Spoke scenario to manage all outbound internet traffic 🌐. In this guide, you'll find step-by-step instructions on: Setting up the Hub & Spoke network architecture Configuring Azure Firewall to control and monitor outbound traffic This tutorial is part of the hub-and-spoke-playground project, which includes various scenarios and scripts to showcase the benefits of the hub-and-spoke network topology in Azure. You can explore more scenarios and resources in the project’s GitHub repository: https://github.com/nicolgit/hub-and-spoke-playground . Would love to hear your thoughts and feedback!
WordPress App how to restrict access to specific pages on the site
Hello all, I have a WordPress App hosted on Azure and I am struggling with how I can secure specific pages from public access. For example: www.mysite.com/wp-admin www.mysite.com/info.php I'd like it so that only specific IP addresses or Microsoft user accounts can access some, such as admin pages and for some pages I'd like no access at all, to where it just blocks any sort of visit. I've viewed the documentation for Front Door and some networking restrictions but that seems to be just IP addresses and I'm confused about how I can set those rule for specific pages within the App. I know WordPress offer plugins which have this sort of functionality but I'd like to take advantage of Azure's security features rather than plugins from WordPress. Any help is very appreciated. Thank youInspection Patterns in Hub-and-Spoke and vWAN Architectures
By shruthi_nair Mays_Algebary Inspection plays a vital role in network architecture, and each customer may have unique inspection requirements. This article explores common inspection scenarios in both Hub-and-Spoke and Virtual WAN (vWAN) topologies. We’ll walk through design approaches assuming a setup with two Hubs or Virtual Hubs (VHubs) connected to on-premises environments via ExpressRoute. The specific regions of the Hubs or VHubs are not critical, as the same design principles can be applied across regions. Scenario1: Hub-and-Spoke Inspection Patterns In the Hub-and-Spoke scenarios, the baseline architecture assumes the presence of two Hub VNets. Each Hub VNet is peered with its local spoke VNets as well as with the other Hub VNet (Hub2-VNet). Additionally, both Hub VNets are connected to both local and remote ExpressRoute circuits to ensure redundancy. Note: In Hub-and-Spoke scenarios, connectivity between virtual networks over ExpressRoute circuits across Hubs is intentionally disabled. This ensures that inter-Hub traffic uses VNet peering, which provides a more optimized path, rather than traversing the ExpressRoute circuit. In Scenario 1, we present two implementation approaches: a traditional method and an alternative leveraging Azure Virtual Network Manager (AVNM). Option1: Full Inspection A widely adopted design pattern is to inspect all traffic, both east-west and north-south, to meet security and compliance requirements. This can be implemented using a traditional Hub-and-Spoke topology with VNet Peering and User-Defined Routes (UDRs), or by leveraging AVNM with Connectivity Configurations and centralized UDR management. In the traditional approach: VNet Peering is used to connect each spoke to its local Hub, and to establish connectivity between the two Hubs. UDRs direct traffic to the firewall as the next hop, ensuring inspection before reaching its destination. These UDRs are applied at the Spoke VNets, the Gateway Subnet, and the Firewall Subnet (especially for inter-region scenarios), as shown in the below diagram. As your environment grows, managing individual UDRs and VNet Peerings manually can become complex. To simplify deployment and ongoing management at scale, you can use AVNM. With AVNM: Use the Hub-and-Spoke connectivity configuration to manage routing within a single Hub. Use the Mesh connectivity configuration to establish Inter-Hub connectivity between the two Hubs. AVNM also enables centralized creation, assignment, and management of UDRs, streamlining network configuration at scale. Connectivity Inspection Table Connectivity Scenario Inspected On-premises ↔ Azure ✅ Spoke ↔ Spoke ✅ Spoke ↔ Internet ✅ Option2: Selective Inspection Between Azure VNets In some scenarios, full traffic inspection is not required or desirable. This may be due to network segmentation based on trust zones, for example, traffic between trusted VNets may not require inspection. Other reasons include high-volume data replication, latency-sensitive applications, or the need to reduce inspection overhead and cost. In this design, VNets are grouped into trusted and untrusted zones. Trusted VNets can exist within the same Hub or across different Hubs. To bypass inspection between trusted VNets, you can connect them directly using VNet Peering or AVNM Mesh connectivity topology. It’s important to note that UDRs are still used and configured as described in the full inspection model (Option 1). However, when trusted VNets are directly connected, system routes (created by VNet Peering or Mesh connectivity) take precedence over custom UDRs. As a result, traffic between trusted VNets bypasses the firewall and flows directly. In contrast, traffic to or from untrusted zones follows the UDRs, ensuring it is routed through the firewall for inspection. t Connectivity Inspection Table Connectivity Scenario Inspected On-premises ↔ Azure ✅ Spoke ↔ Internet ✅ Spoke ↔ Spoke (Same Zones) ❌ Spoke ↔ Spoke (Across Zones) ✅ Option3: No Inspection to On-premises In cases where a firewall at the on-premises or colocation site already inspects traffic from Azure, customers typically aim to avoid double inspection. To support this in the above design, traffic destined for on-premises is not routed through the firewall deployed in Azure. For the UDRs applied to the spoke VNets, ensure that "Propagate Gateway Routes" is set to true, allowing traffic to follow the ExpressRoute path directly without additional inspection in Azure. Connectivity Inspection Table Connectivity Scenario Inspected On-premises ↔ Azure ❌ Spoke ↔ Spoke ✅ Spoke ↔ Internet ✅ Option4: Internet Inspection Only While not generally recommended, some customers choose to inspect only internet-bound traffic and allow private traffic to flow without inspection. In such cases, spoke VNets can be directly connected using VNet Peering or AVNM Mesh connectivity. To ensure on-premises traffic avoids inspection, set "Propagate Gateway Routes" to true in the UDRs applied to spoke VNets. This allows traffic to follow the ExpressRoute path directly without being inspected in Azure. Scenario2: vWAN Inspection Options Now we will explore inspection options using a vWAN topology. Across all scenarios, the base architecture assumes two Virtual Hubs (VHubs), each connected to its respective local spoke VNets. vWAN provides default connectivity between the two VHubs, and each VHub is also connected to both local and remote ExpressRoute circuits for redundancy. It's important to note that this discussion focuses on inspection in vWAN using Routing Intent. As a result, bypassing inspection for traffic to on-premises is not supported in this model. Option1: Full Inspection As noted earlier, inspecting all traffic, both east-west and north-south, is a common practice to fulfill compliance and security needs. In this design, enabling Routing Intent provides the capability to inspect both, private and internet-bound traffic. Unlike the Hub-and-Spoke topology, this approach does not require any UDR configuration. Connectivity Inspection Table Connectivity Scenario Inspected On-premises ↔ Azure ✅ Spoke ↔ Spoke ✅ Spoke ↔ Internet ✅ Option2: Using Different Firewall Flavors for Traffic Inspection Using different firewall flavors inside VHub for traffic inspection Some customers require specific firewalls for different traffic flows, for example, using Azure Firewall for East-West traffic while relying on a third-party firewall for North-South inspection. In vWAN, it’s possible to deploy both Azure Firewall and a third-party network virtual appliance (NVA) within the same VHub. However, as of this writing, deploying two different third-party NVAs in the same VHub is not supported. This behavior may change in the future, so it’s recommended to monitor the known limitations section for updates. With this design, you can easily control which firewall handles East-West versus North-South traffic using Routing Intent, eliminating the need for UDRs. Using different firewall flavors inside VHub for traffic inspection Deploying third-party firewalls in spoke VNets when VHub limitations apply If the third-party firewall you want to use is not supported within the VHub, or if the managed firewall available in the VHub lacks certain required features compared to the version deployable in a regular VNet, you can deploy the third-party firewall in a spoke VNet instead, while using Azure Firewall in the VHub. In this design, the third-party firewall (deployed in a spoke VNet) handles internet-bound traffic, and Azure Firewall (in the VHub) inspects East-West traffic. This setup is achieved by peering the third-party firewall VNet to the VHub, as well as directly peering it with the spoke VNets. These spoke VNets are also connected to the VHub, as illustrated in the diagram below. UDRs are required in the spoke VNets to forward internet-bound traffic to the third-party firewall VNet. East-West traffic routing, however, is handled using the Routing Intent feature, directing traffic through Azure Firewall without the need for UDRs. Deploying third-party firewalls in spoke VNets when VHub limitations apply Note: Although it is not required to connect the third-party firewall VNet to the VHub for traffic flow, doing so is recommended for ease of management and on-premises reachability. Connectivity Inspection Table Connectivity Scenario Inspected On-premises ↔ Azure ✅ Inspected using Azure Firewall Spoke ↔ Spoke ✅ Inspected using Azure Firewall Spoke ↔ Internet ✅ Inspected using Third Party Firewall Option3: Selective Inspection Between Azure VNets Similar to the Hub-and-Spoke topology, there are scenarios where full traffic inspection is not ideal. This may be due to Azure VNets being segmented into trusted and untrusted zones, where inspection is unnecessary between trusted VNets. Other reasons include large data replication between specific VNets or latency-sensitive applications that require minimizing inspection delays and associated costs. In this design, trusted and untrusted VNets can reside within the same VHub or across different VHubs. Routing Intent remains enabled to inspect traffic between trusted and untrusted VNets, as well as internet-bound traffic. To bypass inspection between trusted VNets, you can connect them directly using VNet Peering or AVNM Mesh connectivity. Unlike the Hub-and-Spoke model, this design does not require UDR configuration. Because trusted VNets are directly connected, system routes from VNet peering take precedence over routes learned through the VHub. Traffic destined for untrusted zones will continue to follow the Routing Intent and be inspected accordingly. Connectivity Inspection Table Connectivity Scenario Inspected On-premises ↔ Azure ✅ Spoke ↔ Internet ✅ Spoke ↔ Spoke (Same Zones) ❌ Spoke ↔ Spoke (Across Zones) ✅ Option4: Internet Inspection Only While not generally recommended, some customers choose to inspect only internet-bound traffic and bypass inspection of private traffic. In this design, you only enable the Internet Inspection option within Routing Intent, so private traffic bypasses the firewall entirely. The VHub manages both intra-and inter-VHub routing directly. Internet Inspection Only Connectivity Inspection Table Connectivity Scenario Inspected On-premises ↔ Azure ❌ Spoke ↔ Internet ✅ Spoke ↔ Spoke ❌Accelerate designing, troubleshooting & securing your network with Gen-AI powered tools, now GA.
We are thrilled to announce the general availability of Azure Networking skills in Copilot, an extension of Copilot in Azure and Security Copilot designed to enhance cloud networking experience. Azure Networking Copilot is set to transform how organizations design, operate, and optimize their Azure Network by providing contextualized responses tailored to networking-specific scenarios and using your network topology.Enhancements to the Azure Firewall User Experience
This blog was co-authored by Abhinav Sriram, with contributions from Gopikrishna Kannan. Introduction Everyday, IT administrators face the challenge of securing networks while maintaining application uptime and performance. With a constantly evolving threat landscape and an influx of new vulnerabilities, staying ahead is no easy task. Cloud applications are increasingly leveraging AI to access critical data with reliability, and new applications are rapidly being onboarded. At the same time, organizational security requirements continue to expand in response to government regulations and customer expectations. CIOs are demanding that IT teams do more with less, and the demands can feel daunting. To meet these challenges, IT administrators need modern tools and resources that simplify operations, maintain security, and ensure application performance and compliance. The Azure Firewall team understands these operational needs and the proactive measures administrators require to minimize risk. We're excited to introduce new experiences and capabilities that streamline firewall management, making it easier to monitor, diagnose, and resolve issues quickly. Improved governance and compliance: Through Azure Policies and Azure Advisor recommendations, IT teams can maintain alignment with product and organizational standards, minimizing risk through proactive guidance. Optimized management and diagnostics: Through Azure Firewall Policy Change Tracking and the Diagnose and Solve Blade, administrators can monitor configuration changes and identify solutions to resolve issues quickly. In addition, the new user experiences for setting up a Management NIC and upcoming features like Packet Capture and Maintenance Configuration provide users with the kind of enhanced control and visibility they need for critical services like Firewall. Stay Updated with New Capabilities: The "What's New" experience in Azure Firewall Manager and the Private Preview Program keep administrators informed about updates and provide early access to new features. In this blog, we'll walk through each of these features more in-depth and explore how they assist administrators with tasks at different stages of firewall management beginning with features that bring enhanced governance and compliance to Azure Firewall. Built-In Azure Policies Azure Firewall now includes support for Azure Policy, designed to enhance governance and enforce security best practices. When administrators are initially configuring their firewalls or shortly after deployment, managing configurations across multiple firewalls to meet organizational standards can be complex and prone to oversight or error. These built-in policies simplify this process by automatically applying rules across your firewall resources and ensuring compliance with essential security and operational requirements. For example, administrators can enforce policies requiring Threat Intelligence to be enabled on all firewalls for added protection or mandating that only encrypted traffic is allowed into the environment. These policies offer a streamlined way to maintain consistent security practices, aligning firewall settings with organizational and regulatory standards. For detailed information on configuration and enforcement of these policies, see this blog. Image: Built-in Azure Policies Image: Azure Policy compliance enforcement across Firewall resources Built-In Azure Advisor Recommendations After deploying a firewall, it's essential to monitor any limitations that could impact its performance, particularly in large or complex environments with high traffic volumes. Azure Advisor, a personalized service, offers recommendations to help users optimize Azure resources across five key areas: reliability, security, operational excellence, performance, and cost. With this integration, Azure Advisor can proactively notify you if your Azure Firewall deployment is reaching any limitations, experiencing performance impacts, or has potential misconfigurations. This means you’ll be able to receive timely recommendations to address issues before they affect your network security, ensuring a seamless and secure experience. The current Azure Advisor recommendations include the following: Exceeding rule limitations on Firewall policy: Get notified if your firewall policy is reaching the maximum allowed rules, which may impact performance. Exceeding IP Group limitations on Firewall policy: Alerts for when IP groups used in your firewall policies exceed their defined limits. Exceeding Firewall Policy or Rule Collection Group size: Suggestions to optimize or restructure policies when they grow too large, potentially affecting management or performance. By leveraging these recommendations, you can maintain optimal firewall performance, address potential security risks, and reduce unnecessary costs. Stay tuned for more enhancements as we continue to add more recommendations into Azure Advisor for Azure Firewall. Policy Analytics is another Firewall capability that provides you with insights and recommendations for your environment. Image: Azure Advisor recommendation for “Firewall policy is reaching network rule limitations” Next, let’s dive into the capabilities that help with optimized management and diagnostics. Change Tracking (Preview) Azure Resource Graph (ARG) is an Azure service designed to provide efficient and performant resource exploration at scale. Azure Resource Graph (ARG) provides change analysis data for various management and troubleshooting scenarios. Users can find when changes were detected on an Azure Resource Manager (ARM) property, view property change details and query changes at scale across their subscription, management group, or tenant. ARG change analysis recently added support for RuleCollectionGroups. You can now track changes to Azure Firewall Rule Collection Groups using an Azure Resource Graph query from the Azure Portal ResourceGraphExplorer page using a query like this: Below is a sample change output. This capability can help you track changes made to your Firewall rules helping ensure accountability for a sensitive resource like a Firewall. Diagnose and Solve Blade The Diagnose and Solve problems blade is a feature in Azure that helps customers troubleshoot and solve Azure issues. It helps you explore the most common problems for your Azure Firewalls by providing quick access to service/resource health insights, automated troubleshooters, curated do-it-yourself troubleshooting guides, and additional troubleshooting tools that are all part of the self-help experience designed to help customers solve their problems even before bringing it to Microsoft support teams. To use this feature, you need to navigate to your Firewall in the Azure portal and select Diagnose and solve problems. Image: The Diagnose and Solve blade in Azure Firewall Portal This feature allows you to troubleshoot failures without needing to go through the standard process of filing a support ticket and also provides you with a summarized view of resource health and changes made to the resource in the last 72 hours. Management NIC Changes An Azure Firewall Management NIC separates Firewall management traffic from customer traffic. The firewall routes its management traffic via the dedicated AzureFirewallManagementSubnet (minimum subnet size /26) and its associated public IP address. This feature was previously called Forced Tunneling, as originally, a Management NIC was required only for Forced Tunneling. However, upcoming Firewall features will also require a Management NIC. To support any of these capabilities, you must create an Azure Firewall with the Firewall Management NIC enabled or enable it on an existing Azure Firewall. This is a mandatory requirement to avoid service disruption. To learn more, see Azure Firewall Management NIC | Microsoft Learn. Image: The updated Firewall Management Portal UX in the Create Azure Firewall workflow Lastly, let’s take a look at some of the ways in which you can stay updated with the latest going on with Azure Firewall. Updates to What’s new in Firewall Manager The “What’s new” page in Firewall Manager is kept updated with the most recent product releases across the Network Security portfolio and now easily links to the Copilot for Security integration for Azure Firewall. The Azure Firewall Plugin has four capabilities that help analysts perform detailed investigations of the malicious traffic intercepted by the IDPS feature of their firewalls across their entire fleet using natural language questions in the Copilot for Security standalone experience. To learn more about the user journey and value that Copilot can deliver, see the Azure blog. To see these capabilities in action, take a look at this Tech Community blog, and to get started, see the documentation. Image: Snapshot of the What's New user experience in Azure Firewall Manager Azure Connection Program The Azure Connection Program is an engineering feedback community for Azure customers and partners allowing you to directly engage with the product team of Azure Firewall and get early access to upcoming features like Packet Capture and Maintenance Configurations. This is an avenue where the product team actively engages with customers to get valuable feedback that can help impact the product roadmap. If you’re interested in joining and trying out new features early, please sign up here.
