Help! - How is VNet traffic reaching vWAN/on‑prem when the VNet isn’t connected to the vWAN hub
Hello, I needed some clarity on how the following is working: Attached is a network diagram of our current setup. The function apps (in VNet-1) initiate a connection(s) to a specific IP:Port or FQDN:Port in the on-premises network(s). A Private DNS zone ensures that any FQDN is resolved to the correct internal IP address of the on-prem endpoint. In our setup, both the function app and the external firewall reside in the same VNet. This firewall is described as “Unattached” because it is not the built-in firewall of a secured vWAN hub, but rather an independent Azure Firewall deployed in that VNet. The VNet has a user-defined default route (0.0.0.0/0) directing all outbound traffic to the firewall’s IP. The firewall then filters the traffic, allowing only traffic destined to whitelisted on-premises IP: Port or FQDN: Port combinations (using IP Groups), and blocking everything else. The critical question and the part that I am unable to figure out is: Once the firewall permits a packet, how does Azure know to route it to the vWAN hub and on to the site-to-site VPN? Because VNet-1 truly has no connection at all to the vWAN hub (no direct attachment, no peering, no VPN from the NVA). But the traffic is still reaching the on-prem sites. Unable to figure out how this is happening. Am I missing something obvious? Any help on this would be appreciated. Thank you!
Zero Trust with Azure Firewall, Azure DDoS Protection and Azure WAF: A practical use case
Introduction Zero Trust has emerged as the defining security ethos of the modern enterprise. It is guided by a simple but powerful principle: “Never trust, always verify.” This principle is more relevant now than ever as cyberattacks continue to trend upward in both frequency and impact, affecting organizations of every size and industry. No entity large or small can assume immunity. As a result, adopting Zero Trust is no longer optional, it is a foundational requirement for designing secure, resilient architectures. A key tenet of Zero Trust is the assumption of breach, thus designing systems with the expectation that threats may already exist both outside and inside the network perimeter. To implement this principle, you need multiple, independent security controls that inspect traffic at different layers and enforce least privilege access continuously. Relying on a single security control, even a highly capable one, leaves gaps that modern attackers are adept at exploiting. It is within this context that combining the use of Azure Firewall, Azure DDoS Protection and Azure Web Application Firewall (WAF) services to secure Web Applications while protecting the network perimeter becomes important. Together, these services deliver comprehensive protection across the network and application layers. Defense-in-depth: Why Azure WAF, Azure DDoS Protection and Azure Firewall are essential for Zero Trust In these sections ahead, we examine the common network and application-layer attack vectors that target modern web applications and illustrate how Azure WAF, Azure DDoS protection, and Azure Firewall, when layered strategically, work in tandem to mitigate these threats. The architecture The test environment was designed to reflect a common Azure deployment pattern: Azure DDoS Protection at the edge, to defend against a comprehensive set of network layer (layer 3/4) attacks Azure Application Gateway with WAF, inspecting inbound HTTP traffic for application-layer threats Azure Firewall Premium behind the gateway, providing network-layer protection, deep packet inspection, and outbound traffic governance. A backend subnet hosting an intentionally vulnerable application (OWASP Juice Shop) to simulate real-world attack scenarios. Traffic flows through the DDoS first, then WAF, and then the firewall, before reaching the backend. Outbound traffic from the backend is routed through the firewall for inspection. This ensures that all inbound and outbound traffic is scrutinized. Two access paths that will be tested: Via the Application Gateway public IP, where traffic passes through DDoS, WAF and Firewall. Via the Firewall public IP using a DNAT rule, where traffic bypasses WAF and is inspected only by the Firewall. The following scenarios illustrate how this complementary protection strengthens overall resilience: Scenario 1: SQL injection (application-layer attack) Let’s say an attacker on the internet attempts to access the application’s login endpoint via the Application Gateway IP address and injects a SQL payload into the input field. For example, the attacker submits a request containing the following payload in the User ID field: ?id=' OR 1=1 -- Azure WAF will receive the request, analyze, and if Azure WAF is deployed in Prevention mode, it will immediately detect the SQL injection attempt using its built-in Managed Ruleset. Upon detection, Azure WAF will return a WAF block page, preventing the request from ever reaching the application. By contrast, when the same application is accessed through a firewall-only path (for example, via a DNAT rule on Azure Firewall that exposes the application on port 443), Azure Firewall allows the traffic as it does not perform deep Application layer inspection and SQL injection payloads when embedded within the HTTP request body, appear legitimate at the network layer. Here is a snapshot of the attacker gaining access to the admin role when they insert this SQL injection attack without Azure WAF and only Azure Firewall in the path. Scenario 2: Volumetric and application-layer DDoS attacks Next, the attacker launches a volumetric network layer DDoS (SYN/UDP floods) to saturate bandwidth, but Azure DDoS Network Protection absorbs and scrubs the attack at the edge, so no traffic reaches Application Gateway, WAF, or Firewall. When the network layer attack fails, they shift to HTTP flood attack at the application layer, overwhelming the web application with a high volume of requests. Some requests include exploit attempts, while others are designed purely to exhaust application resources. Azure WAF here, can identify malicious patterns such as: Automated bots lacking proper headers Abnormal request rates Known exploit payloads embedded within requests Malicious IP addresses Note: Azure DDoS Protection is a comprehensive service that provides protection across network layers (Layer 3 and 4), while HTTP DDoS Protection specifically targets application-layer attacks (Layer 7) and is integrated with Azure WAF. They are complementary services designed to defend against different types of threats within the Azure environment. Additionally, if the botnet’s IPs are known threat actors or malicious traffic, Azure Firewall’s threat intelligence and IDPS will be able to flag this traffic too. Together, these services form a complementary, defense-in-depth strategy for protecting Azure workloads against distributed denial-of-service attacks. Scenario 3: Path Traversal Attempt/Information leak: (Application-Layer Attack) Next, the attacker sends HTTP requests to access sensitive system files such as /etc/passwd by sending crafted HTTP requests to the application via the Application Gateway public IP address. The request successfully passes through Azure Application Gateway WAF, as it does not trigger a managed rule violation in this case. However, when the request reaches Azure Firewall, the Firewall’s IDPS detects the malicious pattern in the HTTP header and blocks the connection before it can reach the backend workload. Because the backend connection is denied by Azure Firewall, Application Gateway is unable to establish a successful response and returns a 504 Gateway Timeout to the client, rather than a 403 Forbidden response that would typically be generated by WAF when it blocks traffic. Below is the log from Azure Firewall showing that its able to detect this traffic as – Attempted Information Leak. As seen below, the traffic passed Application Gateway+WAF but was caught by Azure Firewall: This scenario highlights an important architectural outcome: The combination of WAF and Azure Firewall provides layered enforcement, even if an attack manages to slip past Azure WAF, Azure Firewall adds an additional enforcement layer to ensure the application remains protected. Now, let’s look at some more Network Layer attacks: Scenario 4: Network reconnaissance and breach In this scenario, port 3389 is exposed on Application Gateway using the L4 TCP Proxy option. Now, the attacker attempts to scan the Application Gateway on all the ports/protocols and found that port 3389 was open along with other ports such as ports 80, 8080, 3000. Azure WAF will alert us for Layer 7/Application exploit but cannot verify/validate the attack on port 3389 since it was purely Layer 3/4 and contained no HTTP payload for WAF inspection. The L4 proxy listener on App Gateway simply forwards the raw TCP connections to the Azure Firewall behind it. Azure Firewall, however, performs full network‑layer inspection across all ports and protocols, allowing it to detect and alert on this type of L3/L4 reconnaissance even when App Gateway had the port open via the TCP proxy feature. As seen below the traffic passed Application Gateway+WAF but was caught by Azure Firewall since it is non-HTTP: The attacker then tries a different approach: Now the attacker somehow compromises a workstation inside our network and attempts to move laterally to the web server via RDP on port 3389 and/or attempts to exfiltrate and try to access something outside of the network. Azure Firewall located inside the VNet blocks the RDP attempt (if there is no rule allowing it) and if there is, its IDPS flags/blocks the traffic as suspicious. In this case, Azure WAF will not be involved but Azure Firewall inspects this internal and/or outbound traffic and blocks it. This illustrates how a combination of the two stops the attacker at multiple points: firewall foiled the reconnaissance and lateral movement/exfiltration, WAF foiled the application exploit. We can see below the outbound malicious attempt caught by Azure Firewall IDPS: In summary, Azure WAF is like the “bodyguard at the application’s front door” – inspecting every HTTP request in detail and ejecting those carrying hidden weapons or exhibiting bad behavior. It focuses on the web layer, which Azure Firewall or DDoS alone cannot fully protect. If we only had the WAF and no network firewall or DDoS, we’d be safe from many web attacks but would remain exposed to network-level threats (e.g., someone trying to RDP into a VM, or flooding a non-HTTP service). Conversely, if we had only the firewall, a crafty attacker could still exploit a vulnerability in our web app with a well-crafted HTTP request that looks “allowed” to the firewall – that’s where the WAF comes in to catch it. Azure Firewall on the other hand, acts as the “moat and drawbridge” to your cloud network: it keeps out the obvious bad guys at the gate, tightly limits what’s allowed in or out (no implicit trust for internal IPs), and uses threat intel + signatures to sniff out known threats in any traffic it passes, even outbound traffic. The table below shows the traffic flow that will be filtered by Azure WAF vs Azure Firewall. As you can see, layered security is fundamental to Zero Trust Conclusion In a Zero Trust architecture, security cannot rely on implicit trust or a single layer of defense. The combination of Azure Firewall Premium, Azure DDoS protection and Azure Application Gateway WAF exemplifies defense-in-depth by protecting both network and application layers. Organizations hosting internet-facing applications should adopt this layered strategy to reduce exposure to modern threats, prevent lateral movement, and maintain strict control over outbound traffic. By implementing these services together, you align with Microsoft’s recommended best practices for Zero Trust and significantly strengthen your cloud security posture. References: Implement a Zero Trust network for web applications by using Azure Firewall and Azure Application Gateway What is Azure Web Application Firewall? Azure DDoS Protection Overview | Microsoft Learn What is Azure Firewall? Architecture designs using Azure WAF and Azure Firewall together Zero Trust Assessment Overview | Microsoft Learn
How to find Azure Firewall SNAT exhaustion on a compute unit?
I have some applications on my AKS cluster which frequently hits a application server. This application server URL is behind Akamai. When ever applications want to establish an SSL connection with the external URL, it has to go through Azure Firewall. I have occasional connection timeouts if a connection is not establish to Akamai servers in 1s. I saw that the SNAT Utilization is in the range of 10 percent to 30%. I know this graph is smoothened out across instances and can't see which Azure Firewall compute unit is getting overloaded if I have frequent access to one URL which goes through Akamai? Is there any way to find out the reason for these occasional connection timeouts with the external IPs(Akamai)? through logs or by any other means? I believe lack of the SNAT metrics by firewall compute unit is responsible for such tough debugging.How Azure network security can help you meet NIS2 compliance
With the adoption of the NIS2 Directive EU 2022 2555, cybersecurity obligations for both public and private sector organizations have become more strict and far reaching. NIS2 aims to establish a higher common level of cybersecurity across the European Union by enforcing stronger requirements on risk management, incident reporting, supply chain protection, and governance. If your organization runs on Microsoft Azure, you already have powerful services to support your NIS2 journey. In particular Azure network security products such as Azure Firewall, Azure Web Application Firewall WAF, and Azure DDoS Protection provide foundational controls. The key is to configure and operate them in a way that aligns with the directive’s expectations. Important note This article is a technical guide based on the NIS2 Directive EU 2022 2555 and Microsoft product documentation. It is not legal advice. For formal interpretations, consult your legal or regulatory experts. What is NIS2? NIS2 replaces the original NIS Directive 2016 and entered into force on 16 January 2023. Member states must transpose it into national law by 17 October 2024. Its goals are to: Expand the scope of covered entities essential and important entities Harmonize cybersecurity standards across member states Introduce stricter supervisory and enforcement measures Strengthen supply chain security and reporting obligations Key provisions include: Article 20 management responsibility and governance Article 21 cybersecurity risk management measures Article 23 incident notification obligations These articles require organizations to implement technical, operational, and organizational measures to manage risks, respond to incidents, and ensure leadership accountability. Where Azure network security fits The table below maps common NIS2 focus areas to Azure network security capabilities and how they support compliance outcomes. NIS2 focus area Azure services and capabilities How this supports compliance Incident handling and detection Azure Firewall Premium IDPS and TLS inspection, Threat Intelligence mode, Azure WAF managed rule sets and custom rules, Azure DDoS Protection, Azure Bastion diagnostic logs Detect, block, and log threats across layers three to seven. Provide telemetry for triage and enable response workflows that are auditable. Business continuity and resilience Azure Firewall availability zones and autoscale, Azure Front Door or Application Gateway WAF with zone redundant deployments, Azure Monitor with Log Analytics, Traffic Manager or Front Door for failover Improve service availability and provide data for resilience reviews and disaster recovery scenarios. Access control and segmentation Azure Firewall policy with DNAT, network, and application rules, NSGs and ASGs, Azure Bastion for browser based RDP SSH without public IPs, Private Link Enforce segmentation and isolation of critical assets. Support Zero Trust and least privilege for inbound and egress. Vulnerability and misconfiguration defense Azure WAF Microsoft managed rule set based on OWASP CRS. Azure Firewall Premium IDPS signatures Reduce exposure to common web exploits and misconfigurations for public facing apps and APIs. Encryption and secure communications TLS policy: Application Gateway SSL policy; Front Door TLS policy; App Service/PaaS minimum TLS. Inspection: Azure Firewall Premium TLS inspection Inspect and enforce encrypted communication policies and block traffic that violates TLS requirements. Inspect decrypted traffic for threats. Incident reporting and evidence Azure Network Security diagnostics, Log Analytics, Microsoft Sentinel incidents, workbooks, and playbooks Capture and retain telemetry. Correlate events, create incident timelines, and export reports to meet regulator timelines. NIS2 articles in practice Article 21 cybersecurity risk management measures Azure network controls contribute to several required measures: Prevention and detection. Azure Firewall blocks unauthorized access and inspects traffic with IDPS. Azure DDoS Protection mitigates volumetric and protocol attacks. Azure WAF prevents common web exploits based on OWASP guidance. Logging and monitoring. Azure Firewall, WAF, DDoS, and Bastion resources produce detailed resource logs and metrics in Azure Monitor. Ingest these into Microsoft Sentinel for correlation, analytics rules, and automation. Control of encrypted communications. Azure Firewall Premium provides TLS inspection to reveal malicious payloads inside encrypted sessions. Supply chain and service provider management. Use Azure Policy and Defender for Cloud to continuously assess configuration and require approved network security baselines across subscriptions and landing zones. Article 23 incident notification Build an evidence friendly workflow with Sentinel: Early warning within twenty four hours. Use Sentinel analytics rules on Firewall, WAF, DDoS, and Bastion logs to generate incidents and trigger playbooks that assemble an initial advisory. Incident notification within seventy two hours. Enrich the incident with additional context such as mitigation actions from DDoS, Firewall and WAF. Final report within one month. Produce a summary that includes root cause, impact, and corrective actions. Use Workbooks to export charts and tables that back up your narrative. Article 20 governance and accountability Management accountability. Track policy compliance with Azure Policy initiatives for Firewall, DDoS and WAF. Use exemptions rarely and record justification. Centralized visibility. Defender for Cloud’s network security posture views and recommendations give executives and owners a quick view of exposure and misconfigurations. Change control and drift prevention. Manage Firewall, WAF, and DDoS through Network Security Hub and Infrastructure as Code with Bicep or Terraform. Require pull requests and approvals to enforce four eyes on changes. Network security baseline Use this blueprint as a starting point. Adapt to your landing zone architecture and regulator guidance. Topology and control plane Hub and spoke architecture with a centralized Azure Firewall Premium in the hub. Enable availability zones. Deploy Azure Bastion Premium in the hub or a dedicated management VNet; peer to spokes. Remove public IPs from management NICs and disable public RDP SSH on VMs. Use Network Security Hub for at-scale management. Require Infrastructure as Code for all network security resources. Web application protection Protect public apps with Azure Front Door Premium WAF where edge inspection is required. Use Application Gateway WAF v2 for regional scenarios. Enable the Microsoft managed rule set and the latest version. Add custom rules for geo based allow or deny and bot management. enable rate limiting when appropriate. DDoS strategy Enable DDoS Network Protection on virtual networks that contain internet facing resources. Use IP Protection for single public IP scenarios. Configure DDoS diagnostics and alerts. Stream to Sentinel. Define runbooks for escalation and service team engagement. Firewall policy Enable IDPS in alert and then in alert and deny for high confidence signatures. Enable TLS inspection for outbound and inbound where supported. Enforce FQDN and URL filtering for egress. Require explicit allow lists for critical segments. Deny inbound RDP SSH from the internet. Allow management traffic only from Bastion subnets or approved management jump segments. Logging, retention, and access Turn on diagnostic settings for Firewall, WAF, DDoS, and Application Gateway or Front Door. Send to Log Analytics and an archive storage account for long term retention. Set retention per national law and internal policy. Azure Monitor Log Analytics supports table-level retention and archive for up to 12 years, many teams keep a shorter interactive window and multi-year archive for audits. Restrict access with Azure RBAC and Customer Managed Keys where applicable. Automation and playbooks Build Sentinel playbooks for regulator notifications, ticket creation, and evidence collection. Maintain dry run versions for exercises. Add analytics for Bastion session starts to sensitive VMs, excessive failed connection attempts, and out of hours access. Conclusion Azure network security services provide the technical controls most organizations need in order to align with NIS2. When combined with policy enforcement, centralized logging, and automated detection and response, they create a defensible and auditable posture. Focus on layered protection, secure connectivity, and real time response so that you can reduce exposure to evolving threats, accelerate incident response, and meet NIS2 obligations with confidence. References NIS2 primary source Directive (EU) 2022/2555 (NIS2). https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng Azure Firewall Premium features (TLS inspection, IDPS, URL filtering). https://learn.microsoft.com/en-us/azure/firewall/premium-features Deploy & configure Azure Firewall Premium. https://learn.microsoft.com/en-us/azure/firewall/premium-deploy IDPS signature categories reference. https://learn.microsoft.com/en-us/azure/firewall/idps-signature-categories Monitoring & diagnostic logs reference. https://learn.microsoft.com/en-us/azure/firewall/monitor-firewall-reference Web Application Firewall WAF on Azure Front Door overview & features. https://learn.microsoft.com/en-us/azure/frontdoor/web-application-firewall WAF on Application Gateway overview. https://learn.microsoft.com/en-us/azure/web-application-firewall/overview Examine WAF logs with Log Analytics. https://learn.microsoft.com/en-us/azure/application-gateway/log-analytics Rate limiting with Front Door WAF. https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-rate-limit Azure DDoS Protection Service overview & SKUs (Network Protection, IP Protection). https://learn.microsoft.com/en-us/azure/ddos-protection/ddos-protection-overview Quickstart: Enable DDoS IP Protection. https://learn.microsoft.com/en-us/azure/ddos-protection/manage-ddos-ip-protection-portal View DDoS diagnostic logs (Notifications, Mitigation Reports/Flows). https://learn.microsoft.com/en-us/azure/ddos-protection/ddos-view-diagnostic-logs Azure Bastion Azure Bastion overview and SKUs. https://learn.microsoft.com/en-us/azure/bastion/bastion-overview Deploy and configure Azure Bastion. https://learn.microsoft.com/en-us/azure/bastion/tutorial-create-host-portal Disable public RDP and SSH on Azure VMs. https://learn.microsoft.com/en-us/azure/virtual-machines/security-baseline Azure Bastion diagnostic logs and metrics. https://learn.microsoft.com/en-us/azure/bastion/bastion-diagnostic-logs Microsoft Sentinel Sentinel documentation (onboard, analytics, automation). https://learn.microsoft.com/en-us/azure/sentinel/ Azure Firewall solution for Microsoft Sentinel. https://learn.microsoft.com/en-us/azure/firewall/firewall-sentinel-overview Use Microsoft Sentinel with Azure WAF. https://learn.microsoft.com/en-us/azure/web-application-firewall/waf-sentinel Architecture & routing Hub‑spoke network topology (reference). https://learn.microsoft.com/en-us/azure/architecture/networking/architecture/hub-spoke Azure Firewall Manager & secured virtual hub. https://learn.microsoft.com/en-us/azure/firewall-manager/secured-virtual-hub
Spoke-Hub-Hub Traffic with VPN Gateway BGP and Firewall Issue
Hello, I’m facing a situation where I’m trying to have Azure Firewall Inspection on the VPN Gateway VNET-VNET Connectivity. It seems to work if I go from SpokeA-HubAFirewall-HubAVPN—HubBVPN-SpokeB but if I try to go from SpokeA-HubAFirewall-HubAVPN-HubBVM or Inbound Resolver it fails to route correctly according to Connectivity Troubleshooter it stops at HubAVPN with Local Error: RouteMissing but then reaches destination health so makes me believe it’s getting there but not following the route I want it to take which might be causing routing issues. What Am I missing here? This connectivity was working before introducing the Azure Firewall for Inspection with the UDR. Is what I’m trying to accomplish not possible? I’ve tried different types of UDR rules on the Gateway Subnet, and this is my most recent configuration. The reason I’m trying to accomplish this is because I’m seeing a similar error in our Hub-Spoke Hybrid environment and I’m trying to replicate the issue. Current Configuration 2x Hubs with Spoke networks attached so example Hub-Spoke-A Configuration: Hub-A Contains following subnets and Resources VPN Gateway - GateWaySubnet Azure Firewall - AzureFirewallSubnet Inbound Private Resolver - PrivateResolverSubnet Virtual Machine – VM Subnet Gateway Subnet has an attached UDR with the following routes Propagation - True Prefix Destination – Hub-B Next Hop Type – Virtual Appliance Next Hope IP – Hub-A Firewall Prefix Destination – Spoke-B Next Hop Type – Virtual Appliance Next Hope IP – Hub-A Firewall Hub-Spoke-B Configuration: Hub-B Contains following subnets and Resources VPN Gateway - GateWaySubnet Azure Firewall - AzureFirewallSubnet Inbound Private Resolver - PrivateResolverSubnet Virtual Machine – VM Subnet Gateway Subnet has an attached UDR with the following Routes Propagation - True Prefix Destination – Hub-A Next Hop Type – Virtual Appliance Next Hope IP – Hub-B Firewall Prefix Destination – Spoke-A Next Hop Type – Virtual Appliance Next Hope IP – Hub-B Firewall Spoke Subnets has an attached UDR with the following Routes Propagation - True Prefix Destination – 0.0.0.0/0 Next Hop Type – Virtual Appliance Next Hope IP – HubA/HubB Firewall (Depending on what hub its peered to) VPN Gateways HA VNET-VNET with BGP Enabled. I can see that it knows the routes and like I said this was working prior introducing the UDRs for force traffic through the azure firewall.DNS flow trace logs in Azure Firewall are now generally available
Background Azure Firewall helps secure your network by filtering traffic and enforcing policies for your workloads and applications. DNS Proxy, a key capability in Azure Firewall, enables the firewall to act as a DNS forwarder for DNS traffic. Today, we’re introducing the general availability of DNS flow trace logs — a new logging capability that provides end-to-end visibility into DNS traffic and name resolution across your environment, such as viewing critical metadata including query types, response codes, queried domains, upstream DNS servers, and the source and destination IPs of each request. Why DNS flow trace logs? Existing Azure Firewall DNS Proxy logs provide visibility for DNS queries as they initially pass through Azure Firewall. While helpful, customers have asked for deeper insights to troubleshoot, audit, and analyze DNS behavior more comprehensively. DNS flow trace logs address this by offering richer, end-to-end logging, including DNS query paths, cache usage, forwarding decisions, and resolution outcomes. With these logs, you can: Troubleshoot faster with detailed query and response information throughout the full resolution flow Validate caching behavior by determining whether Azure Firewall’s DNS cache was used Gain deeper insights into query types, response codes, forwarding logic, and errors Example scenarios Custom DNS configurations – Verify traffic forwarding paths and ensure custom DNS servers are functioning and responding as expected Connectivity issues – Debug DNS resolution issues that prevent apps from connecting to critical services. Getting started in Azure Portal Navigate to your Azure Firewall resource in the Azure Portal. Select Diagnostic settings under Monitoring. Choose an existing diagnostic setting or create a new one. Under Log, select DNS flow trace logs. Stream logs to Log Analytics, Storage, or Event Hub as needed. Save the settings. Azure Firewall logging ✨ Next steps DNS flow trace logs give you greater visibility and control over DNS traffic in Azure Firewall, helping you secure, troubleshoot, and optimize your network with confidence. 🚀 Try DNS flow trace logs today, now generally available – and share your feedback with the team Learn more about how to configure and monitor these logs in the Azure Firewall monitoring data reference documentation.Using Packet Capture for troubleshooting Azure Firewall flows
This blog is written in collaboration with @GustavoModena Introduction Azure Firewall is a cloud-native and intelligent network firewall security service that provides best of breed threat protection for your cloud workloads running in Azure. It’s a fully stateful firewall as a service with built-in high availability and unrestricted cloud scalability. Azure Firewall provides both east-west and north-south traffic inspection, and it is offered in three SKUs: Basic, Standard and Premium. Azure Firewall also brings powerful logs and metrics to monitor your traffic and operations within the firewall. These logs and metrics include Traffic Analysis, Performance and Health Metrics, and Audit Trail. However, there are situations where you may need a comprehensive network packet capture to troubleshoot and investigate an incident reported by users. We are happy to announce that Microsoft just released the new Packet capture feature and it is Generally Available for Azure Firewall. The Packet capture feature in Azure Firewall is intended for troubleshooting purposes and will allow customers and engineers to debug connectivity issues by tracing packets passing through their Azure Firewall. Azure Firewall Packet Capture shows two packets per flow, one for incoming direction and one for outgoing direction, so you can accurately correlate requests and responses during troubleshooting. What is a network packet capture? Network packet capture is a process that involves capturing network packets as they traverse a network interface. It's a valuable tool for network troubleshooting, analysis, and security monitoring. A network packet capture involves intercepting Internet Protocol (IP) packets for analysis and then saving the packets captured to output files, typically saved in the “.pcap” file extension. Network engineers often utilize packet capturing for troubleshooting and monitoring network traffic to identify security threats. In the event of a data breach or other incident, packet captures offer essential forensic evidence that supports investigations. From a malicious actor’s viewpoint, packet captures can be used to steal passwords and other sensitive data. Unlike active reconnaissance techniques like port scanning, packet capturing can be conducted covertly, leaving no trace for investigators. How Does a Packet Capture Work? Packet captures can be performed using networking equipment like routers, firewalls or switches, or even an engineer’s laptop or desktop. Regardless of the method, packet capture involves creating copies of some or all packets passing through a particular point in the network. Capturing packets from a specific device on the network is the simplest way to start troubleshooting, but there are a few caveats. By default, network interfaces only monitor traffic destined for them. For a more comprehensive view of network traffic, you’ll need to set the interface to promiscuous mode or monitor mode. Many routers, firewalls and other network devices have embedded packet capture functions that can be used to quickly troubleshoot directly from the device's admin console. This capability is now available in Azure Firewall. Scenario (VNET to VNET) In this blog we have VM-1 (10.10.0.4) unsuccessfully trying to establish HTTP (TCP 80)/HTTPS (TCP 443) connection to VM-2 (10.10.0.132) via Azure Firewall. Using Azure Firewall Packet Capture to investigate the connection issue In this section, we will use Azure Firewall Packet Capture to understand why an HTTP/HTTPS connection between VM-1 and VM-2 is not working properly. For this demonstration, we are not going to review the rules and Azure Firewall logs, as the purpose of the blog is to demonstrate the new Packet Capture feature, and we are assuming that the Azure Firewall is configured correctly. Let’s start by making sure that we have all the required resources to take the packet captures from Azure Firewall: Azure Firewall with Management NIC enabled Storage account with a container in which you can store the packet captures Once you have all the required resources available, follow the next steps to start running a Packet Capture via Azure Firewall: Create a SAS URL to the container in the storage account: In the Azure Portal go to Storage Account > Containers and select the 3 ellipses at the very right side of the name of the container that you want to use to store the packet captures and select “Generate SAS”. When defining the parameters of the SAS select “Write” under Permissions, so Azure Firewall will be able to successfully save the packet captures. Then click on “Generate SAS token and URL”. Now, we must go to the Azure Firewall > Packet Capture (under Help) to start running the packet capture. On the Packet Capture page, provide the following information: Packet capture name - the name of one or more capture files. Output SAS URL - the SAS URL of the storage container you created previously. Next, complete the Basic settings for the packet capture: Maximum number of packets - You should limit the packet capture to a set number of packets. Time limit (seconds) - Since the packet capture is intended for troubleshooting purposes, you should limit the capture time. Protocols - the protocols you want the capture to save (values: Any, TCP, UDP, ICMP). TCP Flags - if TCP or Any is selected, you can select which types of packets to save (values: FIN, SYN, RST, PSH, ACK, URG) If both the Maximum number of packets and Time limit are set, the capture ends when the earliest condition is met. So, either when the maximum number of packets is received or when the time limit is reached. In the Filtering section, you can add the source, destination, and destination ports to include in the capture. You must add at least one filter. The packet capture saves bidirectional traffic that matches each row in the filter section. For the source and destination fields you can list multiple commas separated values in a single filter including IP addresses and IP blocks. Select Run Packet Capture after you're done with your configuration. Once the packet capture is complete, you will navigate to the container used in the storage account and download the pcap files. Note that you will see multiple pcap files, this is because each virtual machine in the backend of the firewall has its own file. Analyzing the Packet Captures When using Azure Firewall Packet Capture, you will always see two packets for every single packet in the flow. This is because the firewall captures both the incoming and outgoing directions of the traffic. Understanding this behavior is critical for accurate troubleshooting, as it ensures you can correlate the original request with its corresponding response. The additional scenarios below will explain how to match these incoming and outgoing flows effectively. To analyze the pcap files you need a network protocol analyzer tool. In this blog we are using Wireshark. Note: The intent of this blog is not to show how to use it nor to do advanced troubleshooting using Wireshark. With the pcap files downloaded to your computer, open the files to start your investigation. Since we have multiple files due to the number of active Azure Firewall instances at the time of the packet capture, it may be easier to merge the files. To merge the pcap files, first open one of them using Wireshark and then go to File > Merge and select the second file. There are different ways to merge them, but here we are using “Merge packets chronologically”. Once the pcap files are merged, you will start your investigation by using filters. In this scenario, we want to investigate why an HTTP request from VM-1 to VM-2 on port TCP 80 is not working, and we are using the following filter: Wireshark filter: tcp.port==80 && tcp.port==50245 && ip.addr==10.10.0.132 (VM-2’s IP address) Ok, so here we can see that VM-1 (10.10.0.4) sends a SYN packet from port 53945 to VM-2 (10.10.0.132) on port 80, then VM-2 sends a reset back to VM-1. This behavior shows us that the traffic is successfully passing through Azure Firewall (allowed), and the issue may possibly be something on VM-2. After involving the application team, they have found an issue related to the IIS configuration and it is now fixed as we can see the TCP request being established on ports 80 and 443 in the screenshot below. Other Scenarios DNAT (Inbound traffic) In this scenario we are connecting from a client via Internet to the Azure Firewall’s public IP, using DNAT rules on port 8443. You can see in the screenshot below the incoming request (TCP 3-way handshake) and all the hops until it gets to the Web Server. L3 (and source IP) differs from the incoming packet since its SNATed at L3 while L4 remains the same. For taking the packet capture in this scenario, we are using the following filters: Source: 71.28.90.56,52.176.62.243,10.10.0.64/26,10.10.0.128/26 Destination: 71.28.90.56,52.176.62.243,10.10.0.64/26,10.10.0.128/26 Destination ports: 8443,443 Check below to understand what each one of the IP/IP ranges and ports are used as filters: Client Public IP: 71.28.90.56 Azure Firewall Public IP: 52.176.62.243 Azure Firewall Instance Private IP: 10.10.0.69 (this IP is included in the IP range 10.10.0.64/26) Web Server Private IP: 10.10.0.132 (this IP is included in the IP range 10.10.0.128/26 Azure Firewall Listening Port: 8443 Web Server Listening (translated) Port: 443 In DNAT scenarios, you will notice two SYN packets for the same flow. SYN 1 represents the incoming packet with its original 5-tuple (source IP, destination IP, source port, destination port, protocol), while SYN 2 corresponds to the same flow but with a different 5-tuple after translation by Azure Firewall. This behavior contrasts with VNET-to-VNET flows, where the 5-tuple remains unchanged. When you are SNATing, connecting to/from the Internet, or processing application rules, to see both incoming and outgoing packets you need to make sure that both Public IP address and subnet address space are included. Internet Access (Outbound traffic) In this scenario, we are connecting from an Azure VM to the public IP via Azure Firewall using Network rules. The screenshot illustrates the TCP three-way handshake followed by the HTTP GET request. Notice two SYN packets: one originating from the client to the destination and another from the Azure Firewall instance IP to the destination. In the first two lines, packets flow from the Azure VM IP to the external public IP, followed by the SNATed packet from the Azure Firewall instance IP to the same external address. For this packet capture, the following filters were applied: Source: 10.10.0.132, 10.10.0.0/26 Destination: 151.101.195.5 Destination ports: 80,443 Check below to understand what each one of the IP/IP ranges and ports are used as filters: Azure VM: 10.10.0.132 Azure Firewall Subnet: 10.10.0.0/26 (10.10.0.5 is the instance IP) External Public IP: 151.101.195.5 External Public IP Port: 80 Application Rule Traffic: In this scenario, we are connecting from an Azure VM to the public IP via Azure Firewall using Application rules. While the original request originates from the VM with source IP 10.0.2.4, the Layer 4 details differ from the incoming packet because, during application rule evaluation, the firewall establishes a new outbound connection acting as a proxy. As shown in the image, the SNAT IP of the Azure Firewall instance (10.0.0.5) initiates the connection to the public IP 140.82.112.4. HTTP or TLS keys can be used to match incoming and outgoing packets. L7 remains the same. For packet capture in this scenario, the following filters are applied: Source: 10.0.2.4, 10.0.0.0/24 Destination: 140.82.112.4 Destination ports: 80,443 Check below to understand what each one of the IP/IP ranges and ports are used as filters: Azure VM: 10.0.2.4 Azure Firewall Subnet: 10.0.0.0/24 (10.10.0.5 is the instance SNAT IP) External Public IP: 140.82.112.4 External Public IP Port: 80,443 VNET to VNET with SNAT: In this scenario, the client VM 10.1.0.4 initiates the connection to the server VM 10.0.2.4 but we have enabled SNAT to happen by default. So, the Firewall’s Private IP 172.16.0.5 (SNAT) will initiate a connection with the destination web server as we can see in the below image. For packet capture in this scenario, the following filters are applied: Source: 10.1.0.4, 172.16.0.0/24 Destination: 10.2.0.4 Destination ports: 80,443 Check below to understand what each one of the IP/IP ranges and ports are used as filters: Azure VM: 10.1.0.4 Azure Firewall Subnet: 172.16.0.0/24 (172.16.0.5 is the instance SNAT IP) Web Server Private IP: 10.2.0.4 Web Server Port: 80 Conclusion The availability of Azure Firewall Packet Capture is crucial for effective network and security troubleshooting. It allows network administrators and security professionals to monitor, analyze, and diagnose network traffic in real-time, providing invaluable insights into potential issues and vulnerabilities. By capturing and examining data packets, they can identify anomalies, detect malicious activities, and ensure the integrity and performance of the network. This proactive approach not only enhances the overall security posture but also minimizes downtime and improves the reliability of network services, making packet capture an indispensable tool in the modern IT landscape.
Deploying Third-Party Firewalls in Azure Landing Zones: Design, Configuration, and Best Practices
As enterprises adopt Microsoft Azure for large-scale workloads, securing network traffic becomes a critical part of the platform foundation. Azure’s Well-Architected Framework provides the blueprint for enterprise-scale Landing Zone design and deployments, and while Azure Firewall is a built-in PaaS option, some organizations prefer third-party firewall appliances for familiarity, feature depth, and vendor alignment. This blog explains the basic design patterns, key configurations, and best practices when deploying third-party firewalls (Palo Alto, Fortinet, Check Point, etc.) as part of an Azure Landing Zone. 1. Landing Zone Architecture and Firewall Role The Azure Landing Zone is Microsoft’s recommended enterprise-scale architecture for adopting cloud at scale. It provides a standardized, modular design that organizations can use to deploy and govern workloads consistently across subscriptions and regions. At its core, the Landing Zone follows a hub-and-spoke topology: Hub (Connectivity Subscription): Central place for shared services like DNS, private endpoints, VPN/ExpressRoute gateways, Azure Firewall (or third-party firewall appliances), Bastion, and monitoring agents. Provides consistent security controls and connectivity for all workloads. Firewalls are deployed here to act as the traffic inspection and enforcement point. Spokes (Workload Subscriptions): Application workloads (e.g., SAP, web apps, data platforms) are placed in spoke VNets. Additional specialized spokes may exist for Identity, Shared Services, Security, or Management. These are isolated for governance and compliance, but all connectivity back to other workloads or on-premises routes through the hub. Traffic Flows Through Firewalls North-South Traffic: Inbound connections from the Internet (e.g., customer access to applications). Outbound connections from Azure workloads to Internet services. Hybrid connectivity to on-premises datacenters or other clouds. Routed through the external firewall set for inspection and policy enforcement. East-West Traffic: Lateral traffic between spokes (e.g., Application VNet to Database VNet). Communication across environments like Dev → Test → Prod (if allowed). Routed through an internal firewall set to apply segmentation, zero-trust principles, and prevent lateral movement of threats. Why Firewalls Matter in the Landing Zone While Azure provides NSGs (Network Security Groups) and Route Tables for basic packet filtering and routing, these are not sufficient for advanced security scenarios. Firewalls add: Deep packet inspection (DPI) and application-level filtering. Intrusion Detection/Prevention (IDS/IPS) capabilities. Centralized policy management across multiple spokes. Segmentation of workloads to reduce blast radius of potential attacks. Consistent enforcement of enterprise security baselines across hybrid and multi-cloud. Organizations May Choose Depending on security needs, cost tolerance, and operational complexity, organizations typically adopt one of two models for third party firewalls: Two sets of firewalls One set dedicated for north-south traffic (external to Azure). Another set for east-west traffic (between VNets and spokes). Provides the highest security granularity, but comes with higher cost and management overhead. Single set of firewalls A consolidated deployment where the same firewall cluster handles both east-west and north-south traffic. Simpler and more cost-effective, but may introduce complexity in routing and policy segregation. This design choice is usually made during Landing Zone design, balancing security requirements, budget, and operational maturity. 2. Why Choose Third-Party Firewalls Over Azure Firewall? While Azure Firewall provides simplicity as a managed service, customers often choose third-party solutions due to: Advanced features – Deep packet inspection, IDS/IPS, SSL decryption, threat feeds. Vendor familiarity – Network teams trained on Palo Alto, Fortinet, or Check Point. Existing contracts – Enterprise license agreements and support channels. Hybrid alignment – Same vendor firewalls across on-premises and Azure. Azure Firewall is a fully managed PaaS service, ideal for customers who want a simple, cloud-native solution without worrying about underlying infrastructure. However, many enterprises continue to choose third-party firewall appliances (Palo Alto, Fortinet, Check Point, etc.) when implementing their Landing Zones. The decision usually depends on capabilities, familiarity, and enterprise strategy. Key Reasons to Choose Third-Party Firewalls Feature Depth and Advanced Security Third-party vendors offer advanced capabilities such as: Deep Packet Inspection (DPI) for application-aware filtering. Intrusion Detection and Prevention (IDS/IPS). SSL/TLS decryption and inspection. Advanced threat feeds, malware protection, sandboxing, and botnet detection. While Azure Firewall continues to evolve, these vendors have a longer track record in advanced threat protection. Operational Familiarity and Skills Network and security teams often have years of experience managing Palo Alto, Fortinet, or Check Point appliances on-premises. Adopting the same technology in Azure reduces the learning curve and ensures faster troubleshooting, smoother operations, and reuse of existing playbooks. Integration with Existing Security Ecosystem Many organizations already use vendor-specific management platforms (e.g., Panorama for Palo Alto, FortiManager for Fortinet, or SmartConsole for Check Point). Extending the same tools into Azure allows centralized management of policies across on-premises and cloud, ensuring consistent enforcement. Compliance and Regulatory Requirements Certain industries (finance, healthcare, government) require proven, certified firewall vendors for security compliance. Customers may already have third-party solutions validated by auditors and prefer extending those to Azure for consistency. Hybrid and Multi-Cloud Alignment Many enterprises run a hybrid model, with workloads split across on-premises, Azure, AWS, or GCP. Third-party firewalls provide a common security layer across environments, simplifying multi-cloud operations and governance. Customization and Flexibility Unlike Azure Firewall, which is a managed service with limited backend visibility, third-party firewalls give admins full control over operating systems, patching, advanced routing, and custom integrations. This flexibility can be essential when supporting complex or non-standard workloads. Licensing Leverage (BYOL) Enterprises with existing enterprise agreements or volume discounts can bring their own firewall licenses (BYOL) to Azure. This often reduces cost compared to pay-as-you-go Azure Firewall pricing. When Azure Firewall Might Still Be Enough Organizations with simple security needs (basic north-south inspection, FQDN filtering). Cloud-first teams that prefer managed services with minimal infrastructure overhead. Customers who want to avoid manual scaling and VM patching that comes with IaaS appliances. In practice, many large organizations use a hybrid approach: Azure Firewall for lightweight scenarios or specific environments, and third-party firewalls for enterprise workloads that require advanced inspection, vendor alignment, and compliance certifications. 3. Deployment Models in Azure Third-party firewalls in Azure are primarily IaaS-based appliances deployed as virtual machines (VMs). Leading vendors publish Azure Marketplace images and ARM/Bicep templates, enabling rapid, repeatable deployments across multiple environments. These firewalls allow organizations to enforce advanced network security policies, perform deep packet inspection, and integrate with Azure-native services such as Virtual Network (VNet) peering, Azure Monitor, and Azure Sentinel. Note: Some vendors now also release PaaS versions of their firewalls, offering managed firewall services with simplified operations. However, for the purposes of this blog, we will focus mainly on IaaS-based firewall deployments. Common Deployment Modes Active-Active Description: In this mode, multiple firewall VMs operate simultaneously, sharing the traffic load. An Azure Load Balancer distributes inbound and outbound traffic across all active firewall instances. Use Cases: Ideal for environments requiring high throughput, resilience, and near-zero downtime, such as enterprise data centers, multi-region deployments, or mission-critical applications. Considerations: Requires careful route and policy synchronization between firewall instances to ensure consistent traffic handling. Typically involves BGP or user-defined routes (UDRs) for optimal traffic steering. Scaling is easier: additional firewall VMs can be added behind the load balancer to handle traffic spikes. Active-Passive Description: One firewall VM handles all traffic (active), while the secondary VM (passive) stands by for failover. When the active node fails, Azure service principals manage IP reassignment and traffic rerouting. Use Cases: Suitable for environments where simpler management and lower operational complexity are preferred over continuous load balancing. Considerations: Failover may result in a brief downtime, typically measured in seconds to a few minutes. Synchronization between the active and passive nodes ensures firewall policies, sessions, and configurations are mirrored. Recommended for smaller deployments or those with predictable traffic patterns. Network Interfaces (NICs) Third-party firewall VMs often include multiple NICs, each dedicated to a specific type of traffic: Untrust/Public NIC: Connects to the Internet or external networks. Handles inbound/outbound public traffic and enforces perimeter security policies. Trust/Internal NIC: Connects to private VNets or subnets. Manages internal traffic between application tiers and enforces internal segmentation. Management NIC: Dedicated to firewall management traffic. Keeps administration separate from data plane traffic, improving security and reducing performance interference. HA NIC (Active-Passive setups): Facilitates synchronization between active and passive firewall nodes, ensuring session and configuration state is maintained across failovers. This design choice is usually made during Landing Zone design, balancing security requirements, budget, and operational maturity. : NICs of Palo Alto External Firewalls and FortiGate Internal Firewalls in two sets of firewall scenario 4. Key Configuration Considerations When deploying third-party firewalls in Azure, several design and configuration elements play a critical role in ensuring security, performance, and high availability. These considerations should be carefully aligned with organizational security policies, compliance requirements, and operational practices. Routing User-Defined Routes (UDRs): Define UDRs in spoke Virtual Networks to ensure all outbound traffic flows through the firewall, enforcing inspection and security policies before reaching the Internet or other Virtual Networks. Centralized routing helps standardize controls across multiple application Virtual Networks. Depending on the architecture traffic flow design, use appropriate Load Balancer IP as the Next Hop on UDRs of spoke Virtual Networks. Symmetric Routing: Ensure traffic follows symmetric paths (i.e., outbound and inbound flows pass through the same firewall instance). Avoid asymmetric routing, which can cause stateful firewalls to drop return traffic. Leverage BGP with Azure Route Server where supported, to simplify route propagation across hub-and-spoke topologies. : Azure UDR directing all traffic from a Spoke VNET to the Firewall IP Address Policies NAT Rules: Configure DNAT (Destination NAT) rules to publish applications securely to the Internet. Use SNAT (Source NAT) to mask private IPs when workloads access external resources. Security Rules: Define granular allow/deny rules for both north-south traffic (Internet to VNet) and east-west traffic (between Virtual Networks or subnets). Ensure least privilege by only allowing required ports, protocols, and destinations. Segmentation: Apply firewall policies to separate workloads, environments, and tenants (e.g., Production vs. Development). Enforce compliance by isolating workloads subject to regulatory standards (PCI-DSS, HIPAA, GDPR). Application-Aware Policies: Many vendors support Layer 7 inspection, enabling controls based on applications, users, and content (not just IP/port). Integrate with identity providers (Azure AD, LDAP, etc.) for user-based firewall rules. : Example Configuration of NAT Rules on a Palo Alto External Firewall Load Balancers Internal Load Balancer (ILB): Use ILBs for east-west traffic inspection between Virtual Networks or subnets. Ensures that traffic between applications always passes through the firewall, regardless of origin. External Load Balancer (ELB): Use ELBs for north-south traffic, handling Internet ingress and egress. Required in Active-Active firewall clusters to distribute traffic evenly across firewall nodes. Other Configurations: Configure health probes for firewall instances to ensure faulty nodes are automatically bypassed. Validate Floating IP configuration on Load Balancing Rules according to the respective vendor recommendations. Identity Integration Azure Service Principals: In Active-Passive deployments, configure service principals to enable automated IP reassignment during failover. This ensures continuous service availability without manual intervention. Role-Based Access Control (RBAC): Integrate firewall management with Azure RBAC to control who can deploy, manage, or modify firewall configurations. SIEM Integration: Stream logs to Azure Monitor, Sentinel, or third-party SIEMs for auditing, monitoring, and incident response. Licensing Pay-As-You-Go (PAYG): Licenses are bundled into the VM cost when deploying from the Azure Marketplace. Best for short-term projects, PoCs, or variable workloads. Bring Your Own License (BYOL): Enterprises can apply existing contracts and licenses with vendors to Azure deployments. Often more cost-effective for large-scale, long-term deployments. Hybrid Licensing Models: Some vendors support license mobility from on-premises to Azure, reducing duplication of costs. 5. Common Challenges Third-party firewalls in Azure provide strong security controls, but organizations often face practical challenges in day-to-day operations: Misconfiguration Incorrect UDRs, route tables, or NAT rules can cause dropped traffic or bypassed inspection. Asymmetric routing is a frequent issue in hub-and-spoke topologies, leading to session drops in stateful firewalls. Performance Bottlenecks Firewall throughput depends on the VM SKU (CPU, memory, NIC limits). Under-sizing causes latency and packet loss, while over-sizing adds unnecessary cost. Continuous monitoring and vendor sizing guides are essential. Failover Downtime Active-Passive models introduce brief service interruptions while IPs and routes are reassigned. Some sessions may be lost even with state sync, making Active-Active more attractive for mission-critical workloads. Backup & Recovery Azure Backup doesn’t support vendor firewall OS. Configurations must be exported and stored externally (e.g., storage accounts, repos, or vendor management tools). Without proper backups, recovery from failures or misconfigurations can be slow. Azure Platform Limits on Connections Azure imposes a per-VM cap of 250,000 active connections, regardless of what the firewall vendor appliance supports. This means even if an appliance is designed for millions of sessions, it will be constrained by Azure’s networking fabric. Hitting this cap can lead to unexplained traffic drops despite available CPU/memory. The workaround is to scale out horizontally (multiple firewall VMs behind a load balancer) and carefully monitor connection distribution. 6. Best Practices for Third-Party Firewall Deployments To maximize security, reliability, and performance of third-party firewalls in Azure, organizations should follow these best practices: Deploy in Availability Zones: Place firewall instances across different Availability Zones to ensure regional resilience and minimize downtime in case of zone-level failures. Prefer Active-Active for Critical Workloads: Where zero downtime is a requirement, use Active-Active clusters behind an Azure Load Balancer. Active-Passive can be simpler but introduces failover delays. Use Dedicated Subnets for Interfaces: Separate trust, untrust, HA, and management NICs into their own subnets. This enforces segmentation, simplifies route management, and reduces misconfiguration risk. Apply Least Privilege Policies: Always start with a deny-all baseline, then allow only necessary applications, ports, and protocols. Regularly review rules to avoid policy sprawl. Standardize Naming & Tagging: Adopt consistent naming conventions and resource tags for firewalls, subnets, route tables, and policies. This aids troubleshooting, automation, and compliance reporting. Validate End-to-End Traffic Flows: Test both north-south (Internet ↔ VNet) and east-west (VNet ↔ VNet/subnet) flows after deployment. Use tools like Azure Network Watcher and vendor traffic logs to confirm inspection. Plan for Scalability: Monitor throughput, CPU, memory, and session counts to anticipate when scale-out or higher VM SKUs are needed. Some vendors support autoscaling clusters for bursty workloads. Maintain Firmware & Threat Signatures: Regularly update the firewall’s software, patches, and threat intelligence feeds to ensure protection against emerging vulnerabilities and attacks. Automate updates where possible. Conclusion Third-party firewalls remain a core building block in many enterprise Azure Landing Zones. They provide the deep security controls and operational familiarity enterprises need, while Azure provides the scalable infrastructure to host them. By following the hub-and-spoke architecture, carefully planning deployment models, and enforcing best practices for routing, redundancy, monitoring, and backup, organizations can ensure a secure and reliable network foundation in Azure.
