firewall-faq.yml

### YamlMime:FAQ
metadata:
  title: Azure Firewall FAQ
  description: FAQ for Azure Firewall. A managed, cloud-based network security service that protects your Azure Virtual Network resources.
  services: firewall
  author: duongau
  ms.service: azure-firewall
  ms.custom: devx-track-azurepowershell
  ms.topic: faq
  ms.date: 07/01/2025
  ms.author: duau
title: Azure Firewall FAQ
summary: |

sections:
  - name: General
    questions:
      - question: What is Azure Firewall?
        answer: |
          Azure Firewall is a managed, cloud-based network security service that protects your Azure Virtual Network resources. It's a fully stateful firewall-as-a-service with built-in high availability and unrestricted cloud scalability. You can centrally create, enforce, and log application and network connectivity policies across subscriptions and virtual networks.

      - question: What capabilities does Azure Firewall support?
        answer: |
          For a detailed list of Azure Firewall features, see [Azure Firewall features](features.md).

      - question: What is the typical deployment model for Azure Firewall?
        answer: |
          Azure Firewall can be deployed on any virtual network. However, it's typically deployed on a central virtual network in a hub-and-spoke model, with other virtual networks peered to it. The default route from the peered virtual networks is set to point to this central firewall virtual network. While global virtual network peering is supported, it isn't recommended due to potential performance and latency issues across regions. For optimal performance, deploy one firewall per region.

          This model allows centralized control over multiple spoke VNets across different subscriptions and offers cost savings by avoiding the need to deploy a firewall in each virtual network. Cost savings should be evaluated against the associated peering costs based on traffic patterns.

      - question: How can I deploy Azure Firewall?
        answer: |
          Azure Firewall can be deployed using the Azure portal, PowerShell, REST API, or templates. For step-by-step instructions, see [Tutorial: Deploy and configure Azure Firewall using the Azure portal](tutorial-firewall-deploy-portal.md).

      - question: What are some key Azure Firewall concepts?
        answer: |
          Azure Firewall uses rules and rule collections. A rule collection is a set of rules with the same order and priority. Rule collections are executed in priority order. DNAT rule collections have higher priority than network rule collections, which in turn have higher priority than application rule collections. All rules are terminating.

          There are three types of rule collections:
          - **Application rules**: Configure fully qualified domain names (FQDNs) that can be accessed from a virtual network.
          - **Network rules**: Configure rules with source addresses, protocols, destination ports, and destination addresses.
          - **NAT rules**: Configure DNAT rules to allow incoming Internet or intranet (preview) connections.

          For more information, see [Configure Azure Firewall rules](rule-processing.md).

      - question: Which logging and analytics services does Azure Firewall support?
        answer: |
          Azure Firewall integrates with Azure Monitor for viewing and analyzing logs. Logs can be sent to Log Analytics, Azure Storage, or Event Hubs and analyzed using tools like Log Analytics, Excel, or Power BI. For more information, see [Tutorial: Monitor Azure Firewall logs](./firewall-diagnostics.md).

      - question: How does Azure Firewall differ from NVAs in the marketplace?
        answer: |
          Azure Firewall is a managed, cloud-based network security service that protects virtual network resources. It's a fully stateful firewall-as-a-service with built-in high availability and unrestricted cloud scalability. It's preintegrated with third-party security-as-a-service (SECaaS) providers to enhance security for virtual network and branch Internet connections. For more information, see [Azure network security](../networking/security/index.yml).

      - question: What is the difference between Application Gateway WAF and Azure Firewall?
        answer: |
          Application Gateway WAF provides centralized inbound protection for web applications against common exploits and vulnerabilities. Azure Firewall provides inbound protection for non-HTTP/S protocols (for example, RDP, SSH, FTP), outbound network-level protection for all ports and protocols, and application-level protection for outbound HTTP/S.

      - question: What is the difference between Network Security Groups (NSGs) and Azure Firewall?
        answer: |
          Azure Firewall complements NSGs to provide better "defense-in-depth" network security. NSGs offer distributed network layer traffic filtering to limit traffic within virtual networks in each subscription. Azure Firewall provides centralized, fully stateful network and application-level protection across subscriptions and virtual networks.

      - question: Are Network Security Groups (NSGs) supported on the AzureFirewallSubnet?
        answer: |
          Azure Firewall is a managed service with multiple protection layers, including platform protection with NIC-level NSGs (not viewable). Subnet-level NSGs aren't required on the AzureFirewallSubnet and are disabled to prevent service interruptions.

      - question: What is the added value of Azure Firewall with private endpoints?
        answer: |
          Private endpoints are a component of Private Link, a technology that allows to interact with Azure PaaS services using private IP addresses instead of public ones. Azure Firewall can be used to prevent access to public IP addresses, hence avoiding data exfiltration to Azure services not leveraging Private Link, as well as to implement zero-trust policies by defining who in your organization needs to access those Azure PaaS services, since Private Link per default opens up network access for your whole corporate network.
          
          The right design to inspect traffic to private endpoints with Azure Firewall will depend on your network architecture, you can find more details in the article [Azure Firewall scenarios to inspect traffic destined to a private endpoint](../private-link/inspect-traffic-with-azure-firewall.md).

      - question: What is the added value of Azure Firewall with virtual network service endpoints?
        answer: |
          Virtual Network service endpoints are an alternative to Private Link to control network access to Azure PaaS services. Even if the client still uses public IP addresses to access the PaaS service, the source subnet is made visible so that the destination PaaS service can implement filter rules and restrict access on a per-subnet basis. You can find a detailed comparison between both mechanisms in [Compare Private Endpoints and Service Endpoints](../virtual-network/vnet-integration-for-azure-services.md).
          
          Azure Firewall application rules can be used to make sure that no data exfiltration to rogue services takes place, and to implement access policies with an increased granularity beyond the subnet level. Usually, virtual network service endpoints need to be enabled in the subnet of the client that will connect to an Azure service. However, when inspecting traffic to service endpoints with Azure Firewall, you need to enable the corresponding service endpoint in the Azure Firewall subnet instead and disable them on the subnet of the actual client (usually a spoke virtual network). This way you can use Application Rules in Azure Firewall to control to which Azure services your Azure workloads will have access to.

      - question: What is the pricing for Azure Firewall?
        answer: |
          For pricing details, see [Azure Firewall Pricing](https://azure.microsoft.com/pricing/details/azure-firewall/).

      - question: What are the known service limits for Azure Firewall?
        answer: |
          For service limits, see [Azure subscription and service limits, quotas, and constraints](../azure-resource-manager/management/azure-subscription-service-limits.md#azure-firewall-limits).

      - question: Where does Azure Firewall store customer data?
        answer: |
          Azure Firewall doesn't move or store customer data outside the region where it's deployed.

      - question: Is Azure Firewall in secured virtual hubs (vWAN) supported in Qatar?
        answer: |
          No, Azure Firewall in secured virtual hubs (vWAN) isn't currently supported in Qatar.

  - name: Supported capabilities and features
    questions:
      - question: Does Azure Firewall support inbound traffic filtering?
        answer: |
          Yes, Azure Firewall supports both inbound and outbound traffic filtering. Inbound filtering is typically used for non-HTTP protocols such as RDP, SSH, and FTP. For inbound HTTP and HTTPS traffic, consider using a web application firewall like [Azure Web Application Firewall (WAF)](../web-application-firewall/overview.md) or the TLS offload and deep packet inspection features of [Azure Firewall Premium](./premium-features.md).

      - question: Does Azure Firewall Basic support forced tunneling?
        answer: |
          Yes, Azure Firewall Basic supports forced tunneling.

      - question: Why does a TCP ping or similar tool appear to connect to a target FQDN even when no rule allows the traffic?
        answer: |
          A TCP ping doesn't actually connect to the target FQDN. Azure Firewall blocks connections to any target IP address or FQDN unless explicitly allowed by a rule.

          In the case of a TCP ping, if no rule allows the traffic, the Firewall itself responds to the client's TCP ping request. This response doesn't reach the target IP address or FQDN and isn't logged. If a network rule explicitly allows access to the target IP address or FQDN, the ping request reaches the target server, and its response is relayed back to the client. This event is logged in the Network rules log.

      - question: Does Azure Firewall support BGP peering?
        answer: |
          No, Azure Firewall doesn't natively support BGP peering. However, the [Autolearn SNAT routes feature](../firewall/snat-private-range.md#auto-learn-snat-routes-preview) indirectly uses BGP through Azure Route Server.



      - question: Can Azure Firewall pass ESP packets (IPSec VPN)?
        answer: |
          Azure Firewall does not natively support ESP (Encapsulating Security Payload), but you can allow ESP traffic by configuring a network rule as follows:

          **Azure Firewall configuration (Network Rule):**
          - Protocol: Any
          - Source port: * (Any)
          - Destination port: * (Any)
          - Source/Destination: Specify IP addresses as needed

          This configuration allows ESP packets (IP protocol number 50) and other non-TCP/UDP traffic to match the rule. However, note that Azure Firewall does not inspect ESP payloads.

          **Reference : If using NSG (Network Security Group) instead of Azure Firewall:**
          NSG does not provide a direct option to specify ESP (IP protocol number 50), but ESP packets can be allowed by using the following settings:
          - Protocol: Any
          - Port: * (Any)
          - Source/Destination: Specify IP addresses as needed

          **Recommendations:**
          - For IPsec VPN configurations, using Azure VPN Gateway is recommended.
          - Consider using an NVA (Network Virtual Appliance) pattern depending on your requirements.



  - name: Management and configuration
    questions: 
      - question: How can I stop and start Azure Firewall?
        answer: |
          You can use Azure PowerShell to deallocate and allocate the Azure Firewall. The process varies depending on the configuration.

          **For a firewall without a Management NIC:**
          ```azurepowershell
          # Stop the firewall
          $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
          $azfw.Deallocate()
          Set-AzFirewall -AzureFirewall $azfw

          # Start the firewall
          $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
          $vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
          $publicip1 = Get-AzPublicIpAddress -Name "Public IP1 Name" -ResourceGroupName "RG Name"
          $publicip2 = Get-AzPublicIpAddress -Name "Public IP2 Name" -ResourceGroupName "RG Name"
          $azfw.Allocate($vnet, @($publicip1, $publicip2))
          Set-AzFirewall -AzureFirewall $azfw
          ```

          **For a firewall with a Management NIC:**
          ```azurepowershell
          # Stop the firewall
          $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
          $azfw.Deallocate()
          Set-AzFirewall -AzureFirewall $azfw

          # Start the firewall
          $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
          $vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
          $pip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
          $mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
          $azfw.Allocate($vnet, $pip, $mgmtPip)
          Set-AzFirewall -AzureFirewall $azfw
          ```

          **For a firewall in a secured virtual hub:**
          ```azurepowershell
          # Stop the firewall
          $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
          $azfw.Deallocate()
          Set-AzFirewall -AzureFirewall $azfw

          # Start the firewall
          $virtualhub = Get-AzVirtualHub -ResourceGroupName "vHUB RG Name" -Name "vHUB Name"
          $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "Firewall RG Name"
          $azfw.Allocate($virtualhub.Id)
          Set-AzFirewall -AzureFirewall $azfw
          ```

          > [!NOTE]
          > When stopping and starting the firewall, billing stops and starts accordingly. However, the private IP address might change, which can affect connectivity if route tables are configured.

      - question: How can I configure availability zones after deployment?
        answer: |
          It's recommended to configure availability zones during initial deployment. However, you can reconfigure them after deployment if:
          - The firewall is deployed in a virtual network (not supported in secured virtual hubs).
          - The region supports availability zones.
          - All attached public IP addresses are configured with the same zones.

          To reconfigure availability zones:
          1. Deallocate the firewall:
             ```azurepowershell
             $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
             $azfw.Deallocate()
             Set-AzFirewall -AzureFirewall $azfw
             ```
          2. Update the zone configuration and allocate the firewall:
             ```azurepowershell
             $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
             $vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
             $pip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
             $mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
             $azfw.Allocate($vnet, $pip, $mgmtPip)
             $azfw.Zones = 1, 2, 3
             Set-AzFirewall -AzureFirewall $azfw
             ```

      - question: Are there any Azure firewall resource group restrictions?
        answer: |
          Yes:
          - The Azure Firewall and virtual network must be in the same resource group.
          - The public IP address can be in a different resource group.
          - All resources (Azure firewall, virtual network, public IP) must be in the same subscription.

      - question: What does provisioning state **Failed** mean?
        answer: |
          A **Failed** provisioning state indicates that a configuration update failed on one or more backend instances. The Azure Firewall remains operational, but the configuration might be inconsistent. Retry the update until the provisioning state changes to **Succeeded**.

      - question: How does Azure Firewall handle planned maintenance and unplanned failures?
        answer: |
          Azure Firewall uses an active-active configuration with multiple backend nodes. During planned maintenance, connection draining ensures graceful updates. For unplanned failures, a new node replaces the failed one, and connectivity is typically restored within 10 seconds.

      - question: Is there a character limit for a firewall name?
        answer: |
          Yes, firewall names are limited to 50 characters.

      - question: Why does Azure Firewall need a /26 subnet size?
        answer: |
          A /26 subnet ensures sufficient IP addresses for scaling as the Azure Firewall provisions extra virtual machine instances.

      - question: Does the firewall subnet size need to change as the service scales?
        answer: |
          No, a /26 subnet is sufficient for all scaling scenarios.

      - question: How can I increase my firewall throughput?
        answer: |
          Azure Firewall scales automatically based on CPU usage, throughput, and connection count. Throughput capacity ranges from 2.5–3 Gbps initially to 30 Gbps (Standard SKU) or 100 Gbps (Premium SKU).

      - question: Are there limits for the number of IP addresses supported by IP Groups?
        answer: |
          Yes. For details, see [Azure subscription and service limits, quotas, and constraints](../azure-resource-manager/management/azure-subscription-service-limits.md#azure-firewall-limits).

      - question: Can I move an IP Group to another resource group?
        answer: |
          No, moving an IP Group to another resource group isn't currently supported.

      - question: What is the TCP Idle Timeout for Azure Firewall?
        answer: |
          A standard behavior of a network firewall is to ensure TCP connections are kept alive and to promptly close them if there's no activity. Azure Firewall TCP Idle Timeout is four minutes. This setting isn't user configurable, but you can contact Azure Support to increase the Idle Timeout for inbound and outbound connections up to 15 minutes. Idle Timeout for east-west traffic can't be changed.

          If a period of inactivity is longer than the timeout value, there's no guarantee that the TCP or HTTP session is maintained. A common practice is to use a TCP keep-alive. This practice keeps the connection active for a longer period. For more information, see the [.NET examples](/dotnet/api/system.net.servicepoint.settcpkeepalive).

      - question: Can I deploy Azure Firewall without a public IP address?
        answer: |
          Yes, but you must configure the firewall in Forced Tunneling Mode. This configuration creates a management interface with a public IP address that is used by Azure Firewall for its operations. This public IP address is for management traffic. It's used exclusively by the Azure platform and can't be used for any other purpose. The tenant data path network can be configured without a public IP address, and Internet traffic can be forced tunneled to another Firewall or completely blocked.

      - question: Is there a way to automatically back up Azure Firewall and policies?
        answer: |
          Yes. For more information, see [Backup Azure Firewall and Azure Firewall Policy with Logic Apps](https://techcommunity.microsoft.com/t5/azure-network-security-blog/backup-azure-firewall-and-azure-firewall-policy-with-logic-apps/ba-p/3613928).

  - name: Connectivity and routing
    questions: 
      
      - question: How do I set up Azure Firewall with my service endpoints?
        answer: |
          For secure access to PaaS services, we recommend service endpoints. You can choose to enable service endpoints in the Azure Firewall subnet and disable them on the connected spoke virtual networks. This way you benefit from both features: service endpoint security and central logging for all traffic.

      - question: Can Azure Firewall in a hub virtual network forward and filter network traffic between multiple spoke virtual networks?
        answer: |
          Yes, you can use Azure Firewall in a hub virtual network to route and filter traffic between multiple spoke virtual network. Subnets in each of the spoke virtual networks must have a UDR pointing to the Azure Firewall as a default gateway for this scenario to work properly.

      - question: Can Azure Firewall forward and filter network traffic between subnets in the same virtual network or peered virtual networks?
        answer: |
          Yes. However, configuring the UDRs to redirect traffic between subnets in the same virtual network requires more attention. While using the virtual network address range as a target prefix for the UDR is sufficient, this also routes all traffic from one machine to another machine in the same subnet through the Azure Firewall instance. To avoid this, include a route for the subnet in the UDR with a next hop type of **virtual network**. Managing these routes might be cumbersome and prone to error. The recommended method for internal network segmentation is to use Network Security Groups, which don't require UDRs.

      - question: Does Azure Firewall outbound SNAT between private networks?
        answer: |
          Azure Firewall doesn't SNAT when the destination IP address is a private IP range per [IANA RFC 1918](https://tools.ietf.org/html/rfc1918) or [IANA RFC 6598](https://datatracker.ietf.org/doc/html/rfc6598) for private networks. If your organization uses a public IP address range for private networks, Azure Firewall SNATs the traffic to one of the firewall private IP addresses in AzureFirewallSubnet. You can configure Azure Firewall to **not** SNAT your public IP address range. For more information, see [Azure Firewall SNAT private IP address ranges](snat-private-range.md).

          In addition, traffic processed by application rules are always SNAT-ed. If you want to see the original source IP address in your logs for FQDN traffic, you can use network rules with the destination FQDN.

      - question: Is forced tunneling/chaining to a Network Virtual Appliance supported?
        answer: |
          Forced tunneling is supported when creating a new firewall, and it is also supported for existing firewalls by adding a management NIC for forced tunneling. For more details about new deployments, see [Azure Firewall forced tunneling](forced-tunneling.md). For existing firewalls, see [Azure Firewall Management NIC](management-nic.md).

          Azure Firewall must have direct Internet connectivity. If your AzureFirewallSubnet learns a default route to your on-premises network via BGP, you must override this with a 0.0.0.0/0 UDR with the **NextHopType** value set as **Internet** to maintain direct Internet connectivity.

          If your configuration requires forced tunneling to an on-premises network and you can determine the target IP prefixes for your Internet destinations, you can configure these ranges with the on-premises network as the next hop via a user defined route on the AzureFirewallSubnet. Or, you can use BGP to define these routes.

      - question: How do wildcards work in target URLs and target FQDNs in application rules?
        answer: |
          - **URL** - Asterisks work when placed on the right-most or left-most side. If it is on the left, it can't be part of the FQDN.
          - **FQDN** - Asterisks work when placed on the left-most side.
          - **GENERAL** - Asterisks on the left-most side mean literally _anything_ to the left matches, meaning multiple subdomains and/or potentially unwanted domain name variations are matched - see the following examples.

          Examples:

            | Type | Rule | Supported? | Positive examples |
            |--|--|--|--|
            | TargetURL | `www.contoso.com` | Yes | `www.contoso.com`<br>`www.contoso.com/` |
            | TargetURL | `*.contoso.com` | Yes | `any.contoso.com/`<br>`sub1.any.contoso.com` |
            | TargetURL | `*contoso.com` | Yes | `example.anycontoso.com`<br>`sub1.example.contoso.com`<br>`contoso.com`<br>Warning: this usage of wildcard also allows potentially undesired/risky variations such as `th3re4lcontoso.com` - use with caution. |
            | TargetURL | `www.contoso.com/test` | Yes | `www.contoso.com/test`<br>`www.contoso.com/test/`<br>`www.contoso.com/test?with_query=1` |
            | TargetURL | `www.contoso.com/test/*` | Yes | `www.contoso.com/test/anything`<br>Note: `www.contoso.com/test` **doesn't** match (last slash) |
            | TargetURL | `www.contoso.*/test/*` | No |  |
            | TargetURL | `www.contoso.com/test?example=1` | No |  |
            | TargetURL | `www.contoso.*` | No |  |
            | TargetURL | `www.*contoso.com` | No |  |
            | TargetURL | `www.contoso.com:8080` | No |  |
            | TargetURL | `*.contoso.*` | No |  |
            | TargetFQDN | `www.contoso.com` | Yes | `www.contoso.com` |
            | TargetFQDN | `*.contoso.com` | Yes | `any.contoso.com`<br><br>Note: If you want to specifically allow `contoso.com`, you must include contoso.com in the rule. Otherwise, the connection is dropped by default because the request doesn't match any rule. |
            | TargetFQDN | `*contoso.com` | Yes | `example.anycontoso.com`<br>`contoso.com` |
            | TargetFQDN | `www.contoso.*` | No |  |
            | TargetFQDN | `*.contoso.*` | No |  |

      - question: Does Azure Firewall allow access to Active Directory by default?
        answer: |
          No. Azure Firewall blocks Active Directory access by default. To allow access, configure the AzureActiveDirectory service tag. For more information, see [Azure Firewall service tags](service-tags.md).

      - question: Can I exclude an FQDN or an IP address from Azure Firewall Threat Intelligence based filtering?
        answer: |
          Yes, you can use Azure PowerShell to do it:

          ```azurepowershell
          # Add a Threat Intelligence allowlist to an Existing Azure Firewall.

          # Create the allowlist with both FQDN and IPAddresses
          $fw = Get-AzFirewall -Name "Name_of_Firewall" -ResourceGroupName "Name_of_ResourceGroup"
          $fw.ThreatIntelWhitelist = New-AzFirewallThreatIntelWhitelist `
             -FQDN @("fqdn1", "fqdn2", …) -IpAddress @("ip1", "ip2", …)

          # Or Update FQDNs and IpAddresses separately
          $fw = Get-AzFirewall -Name $firewallname -ResourceGroupName $RG
          $fw.ThreatIntelWhitelist.IpAddresses = @($fw.ThreatIntelWhitelist.IpAddresses + $ipaddresses)
          $fw.ThreatIntelWhitelist.fqdns = @($fw.ThreatIntelWhitelist.fqdns + $fqdns)


          Set-AzFirewall -AzureFirewall $fw
          ```

      - question: Why can a TCP ping and similar tools successfully connect to a target FQDN even when no rule on Azure Firewall allows that traffic?
        answer: |
          A TCP ping isn't actually connecting  to the target FQDN. Azure Firewall doesn't allow a connection to any target IP address/FQDN unless there's an explicit rule that allows it.

          TCP ping is a unique use case where if there's no allowed rule, the Firewall itself responds to the client's TCP ping request even though the TCP ping doesn't reach the target IP address/FQDN. In this case, the event isn't logged. If there's a network rule that allows access to the target IP address/FQDN, then the ping request reaches the target server and its response is relayed back to the client. This event is logged in the Network rules log.


      - question: Why do TCP ping and similar tools successfully connect to a target FQDN/IP address on ports 80, 443, and 1433 but aren't observed in the Azure Firewall logs?
        answer: |
          Azure Firewall acts as a passive listener for ports 80, 443, and 1433. Azure Firewall doesn't log TCP SYN packets on these ports unless there's application traffic. The HTTP GET request and TLS client hello are logged in Azure Firewall.

      - question: Are there limits for the number of IP addresses supported by IP Groups?
        answer: |
          Yes. For more information, see [Azure subscription and service limits, quotas, and constraints](../azure-resource-manager/management/azure-subscription-service-limits.md#azure-firewall-limits)

      - question: Can I move an IP Group to another resource group?
        answer: No, moving an IP Group to another resource group isn't currently supported.

      - question: What is the TCP Idle Timeout for Azure Firewall?
        answer: |
          A standard behavior of a network firewall is to ensure TCP connections are kept alive and to promptly close them if there's no activity. Azure Firewall TCP Idle Timeout is four minutes. This setting isn't user configurable, but you can contact Azure Support to increase the Idle Timeout for inbound and outbound connections up to 15 minutes. Idle Timeout for east-west traffic can't be changed.

          If a period of inactivity is longer than the timeout value, there's no guarantee that the TCP or HTTP session is maintained. A common practice is to use a TCP keep-alive. This practice keeps the connection active for a longer period. For more information, see the [.NET examples](/dotnet/api/system.net.servicepoint.settcpkeepalive).

      - question: Can I deploy Azure Firewall without a public IP address?
        answer: Yes, but you must configure the firewall in Forced Tunneling Mode. This configuration creates a management interface with a public IP address that is used by Azure Firewall for its operations. This public IP address is for management traffic. It's used exclusively by the Azure platform and can't be used for any other purpose. The tenant data path network can be configured without a public IP address, and Internet traffic can be forced tunneled to another Firewall or completely blocked.

      - question: Where does Azure Firewall store customer data?
        answer: Azure Firewall doesn't move or store customer data out of the region it's deployed in.

      - question: Is there a way to automatically back up Azure Firewall and policies?
        answer: Yes. For more information, see [Backup Azure Firewall and Azure Firewall Policy with Logic Apps](https://techcommunity.microsoft.com/t5/azure-network-security-blog/backup-azure-firewall-and-azure-firewall-policy-with-logic-apps/ba-p/3613928).

      - question: Is Azure Firewall in secured virtual hubs (vWAN) supported in Qatar?
        answer: No, currently Azure Firewall in secured virtual hubs (vWAN) isn't supported in Qatar.

      - question: How many parallel connections can Azure Firewall support?
        answer: |
          Azure Firewall uses Azure Virtual Machines underneath that have a [hard limit number of connections](/azure/virtual-network/virtual-machine-network-throughput#flow-limits-and-active-connections-recommendations). The total number of active connections per virtual machine is 250k.

          The total limit per firewall is the virtual machine connection limit (250k) x the number of virtual machines in the firewall backend pool. Azure Firewall starts with two virtual machines and scales out based on CPU usage and throughput.

      - question: What is the SNAT TCP/UDP port reuse behavior in Azure Firewall?
        answer: |
          Azure Firewall currently uses TCP/UDP source ports for outbound SNAT traffic, with no idle wait time. When a TCP/UDP connection is closed, the TCP port used is immediately seen as available for upcoming connections.

          As a workaround for certain architectures, you can deploy and scale with [NAT Gateway with Azure Firewall](../nat-gateway/tutorial-hub-spoke-nat-firewall.md) to provide a wider pool of SNAT ports for variability and availability.
      
      - question: What are NAT behaviors in Azure Firewall?
        answer: |
          Specific NAT behaviors depend on the firewall's configuration and the type of NAT that's configured. For example, the firewall has DNAT rules for inbound traffic, and network rules and application rules for outbound traffic through the firewall.

          For more information, see [Azure Firewall NAT Behaviors](https://techcommunity.microsoft.com/t5/azure-network-security-blog/azure-firewall-nat-behaviors/ba-p/3825834).

  - name: Timeouts and scaling
    questions:
      - question: How does connection draining work?
        answer: |
          For any planned maintenance, connection draining logic gracefully updates backend nodes. Azure Firewall waits 90 seconds for existing connections to close. In the first 45 seconds, the backend node doesn't accept new connections, and in the remaining time it responds with `RST` to all incoming packets. If needed, clients can automatically re-establish connectivity to another backend node.

      - question: How does Azure Firewall handle VM instance shutdowns during Virtual Machine Scale Set scale in (scale down) or fleet software upgrades?
        answer: |
          An Azure Firewall VM instance shutdown might occur during Virtual Machine Scale Set scale in (scale down) or during fleet software upgrade. In these cases, new incoming connections are load balanced to the remaining firewall instances and aren't forwarded to the down firewall instance. After 45 seconds, the firewall starts rejecting existing connections by sending TCP RST packets. After another 45 seconds the firewall VM shuts down. For more information, see [Load Balancer TCP Reset and Idle Timeout](../load-balancer/load-balancer-tcp-reset.md).

      - question: How long does it take for Azure Firewall to scale out?
        answer: |
          Azure Firewall gradually scales when average throughput or CPU consumption is at 60%, or the number of connections usage is at 80%. For example, it starts to scale out when it reaches 60% of its maximum throughput. Maximum throughput numbers vary based on the Azure Firewall SKU and enabled features. For more information, see [Azure Firewall performance](firewall-performance.md).
          
          Scale out takes five to seven minutes. When performance testing, make sure you test for at least 10 to 15 minutes, and start new connections to take advantage of newly created Azure Firewall nodes.

      - question: How does Azure Firewall handle idle timeouts?
        answer: |
          When a connection has an Idle Timeout (four minutes of no activity), Azure Firewall gracefully terminates the connection by sending a TCP RST packet.
  
  - name: Customer-controlled maintenance
    questions:
      - question: |
          What type of maintenance does customer-controlled maintenance support?
        answer: |
          Azure services undergo regular maintenance updates to enhance functionality, reliability, performance, and security. With a configured maintenance period, guest OS maintenance and service maintenance are performed during that window. However, customer-controlled maintenance doesn't include host updates or critical security updates.

      - question: |
          Can I get advanced notification of the maintenance event?
        answer: |
          Advanced notifications for Azure Firewall maintenance aren't available.

      - question: |
          Can I configure a maintenance window shorter than five hours?
        answer: |
          No, a minimum five-hour maintenance window is required.

      - question: |
          Can I configure a maintenance window other than a daily schedule?
        answer: |
          No, maintenance windows is currently be configured to recur daily.

      - question: |
          Are there cases where I can't control certain updates?
        answer: |
          Customer-controlled maintenance supports guest OS and service updates, which account for most maintenance items of concern to customers. However, some updates, such as host updates, are outside the scope of customer-controlled maintenance. In rare cases, we might override your control of the maintenance window to address high-severity security issues.

      - question: |
          Do maintenance configuration resources need to be in the same region as the Azure Firewall?
        answer: |
          Yes.

      - question: |
          Can we create more than one maintenance configuration for a single Azure Firewall?
        answer: |
          No. Currently, only one maintenance configuration can be associated with an Azure Firewall.

      - question: |
          Which Azure Firewall SKUs can I configure to use customer-controlled maintenance?
        answer: |
          All Azure Firewall SKUs - Basic, Standard, and Premium support customer-controlled maintenance.

      - question: |
          How long does it take for a maintenance configuration policy to become effective after it's assigned to the Azure Firewall?
        answer: |
          It might take up to 24 hours for the Azure Firewall to follow the maintenance schedule after the maintenance policy is associated.

      - question: |
          I scheduled a maintenance window for a future date for one of my Azure Firewall resources. Are maintenance activities paused on this resource until then?
        answer: |
          Maintenance activities on your Azure Firewall aren't paused during the period preceding the scheduled maintenance window. For days that aren't included in your maintenance schedule, regular maintenance operations continue as usual on the resource.

      - question: |
          How do I find out more about customer-controlled maintenance on the Azure Firewall?
        answer: |
          For more information, see [Configure customer-controlled maintenance](customer-controlled-maintenance.md).