Firewall and Application Gateway for virtual networks

Application Gateway
Firewall
Front Door
Kubernetes Service
Virtual Network
Web Application Firewall

To secure Azure application workloads, you use protective measures, such as authentication and encryption, in the applications themselves. You can also add security layers to the virtual machine (VM) networks that host the applications. The layers protect inbound flows from users. They also protect outbound flows to the internet that your application might require. This article describes Azure Virtual Network security services like Azure Firewall and Azure Application Gateway, when to use each service, and network design options that combine both.

  • Azure Firewall is a managed next-generation firewall that offers network address translation (NAT). Azure Firewall bases packet filtering on Internet Protocol (IP) addresses and Transmission Control Protocol and User Datagram Protocol (TCP/UDP) ports, or on application-based HTTP(S) or SQL attributes. Azure Firewall also applies Microsoft threat intelligence to identify malicious IP addresses. For more information, see the Azure Firewall documentation.
  • Azure Firewall Premium includes all functionality of Azure Firewall Standard and other features, such as TLS-inspection and Intrusion Detection and Protection System (IDPS).
  • Azure Application Gateway is a managed web traffic load balancer and HTTP(S) full reverse proxy that can do Secure Socket Layer (SSL) encryption and decryption. Application Gateway also uses Web Application Firewall to inspect web traffic and detect attacks at the HTTP layer. For more information, see the Application Gateway documentation.
  • Azure Web Application Firewall (WAF) is an optional addition to Azure Application Gateway. It provides inspection of HTTP requests, and it prevents malicious attacks at the web layer, such as SQL Injection or Cross-Site Scripting. For more information, see the Web Application Firewall documentation.

These Azure services are complementary. One or the other may be best for your workloads, or you can use them together for optimal protection at both the network and application layers. Use the following decision tree and the examples in this article to determine the best security option for your application's virtual network.

Azure Firewall and Azure Application Gateway use different technologies, and they support securitization of different flows:

Application Flow Can be filtered by Azure Firewall Can be filtered by WAF on Application Gateway
HTTP(S) traffic from on-premises/internet to Azure (inbound) Yes Yes
HTTP(S) traffic from Azure to on-premises/internet (outbound) Yes No
Non-HTTP(S) traffic, inbound/outbound Yes No

Depending on the network flows an application requires, the design can be different on a per-application basis. The following diagram offers a simplified decision tree that helps choosing the recommended approach for an application. The decision depends on whether the application is published via HTTP(S) or some other protocol:

Virtual network security decision tree

This article will cover the widely recommended designs from the flow chart, and others that are applicable in less common scenarios:

  • Azure Firewall alone, when there are no web applications in the virtual network. It will control both inbound traffic to the applications and outbound traffic.
  • Application Gateway alone, when only web applications are in the virtual network, and network security groups (NSGs) provide sufficient output filtering. This scenario is typically not recommended because of the rich functionality of Azure Firewall over NSGs. That functionality can prevent many attack scenarios (such as data exfiltration), so this scenario isn't documented in the flow chart above.
  • Azure Firewall and Application Gateway in parallel, which is one of the most common designs. Use this combination when you want Azure Application Gateway to protect HTTP(S) applications from web attacks, and Azure Firewall to protect all other workloads and filter outbound traffic.
  • Application Gateway in front of Azure Firewall, when you want Azure Firewall to inspect all traffic, WAF to protect web traffic, and the application to know the client's source IP address. With Azure Firewall Premium and TLS inspection, this design supports the end-to-end SSL scenario as well.
  • Azure Firewall in front of Application Gateway, when you want Azure Firewall to inspect and filter traffic before it reaches the Application Gateway. Because the Azure Firewall isn't going to decrypt HTTPS traffic, the functionality that it's adding to the Application Gateway is limited. This scenario isn't documented in the flow chart above.

In the last part of this article, variations of the previous fundamental designs are described. These variations include:

You can add other reverse proxy services like an API Management gateway or Azure Front Door. Or you can replace the Azure resources with third-party network virtual appliances.

Azure Firewall only

If there are no web-based workloads in the virtual network that can benefit from WAF, you can use Azure Firewall only. The design in this case is simple, but reviewing the packet flow will help understand more complex designs.

The following table summarizes the traffic flows for this scenario:

Flow Goes through Application Gateway / WAF Goes through Azure Firewall
HTTP(S) traffic from internet/onprem to Azure N/A Yes (see below)
HTTP(S) traffic from Azure to internet/onprem N/A Yes
Non-HTTP(S) traffic from internet/onprem to Azure N/A Yes
Non-HTTP(S) traffic from Azure to internet/onprem N/A Yes

Azure Firewall won't inspect inbound HTTP(S) traffic. But it will be able to apply L3/L4 rules and FQDN-based application rules. Azure Firewall will inspect outbound HTTP(S) traffic depending on the Azure Firewall tier and whether you configure TLS inspection:

  • Azure Firewall Standard will only inspect Layer 3-4 attributes of the packets in network rules, and the Host HTTP header in application rules.
  • Azure Firewall Premium will add capabilities such as inspecting other HTTP headers (such as the User-Agent) and enabling TLS inspection for deeper packet analysis. Azure Firewall isn't equivalent to a Web Application Firewall. If you have web workloads in your Virtual Network, using WAF is highly recommended.

The following packet walk example shows how a client accesses a VM-hosted application from the public internet. The diagram includes only one VM for simplicity. For higher availability and scalability, you'd have multiple application instances behind a load balancer.

Firewall only

  1. The client starts the connection to the public IP address of the Azure Firewall:
    • Source IP address: ClientPIP
    • Destination IP address: AzFwPIP
  2. The Azure Firewall Destination NAT (DNAT) rule translates the destination IP address to the application IP address inside the virtual network. The Azure Firewall also Source NATs (SNATs) the packet if it does DNAT. For more information, see Azure Firewall known issues. The VM sees the following IP addresses in the incoming packet:
    • Source IP address: 192.168.100.7
    • Destination IP address: 192.168.1.4
  3. The VM answers the application request, reversing source and destination IP addresses. The inbound flow doesn't require a user-defined route (UDR), because the source IP is Azure Firewall's IP address. The UDR in the diagram for 0.0.0.0/0 is for outbound connections, to make sure packets to the public internet go through the Azure Firewall.
    • Source IP address: 192.168.1.4
    • Destination IP address: 192.168.100.7
  4. Finally, Azure Firewall undoes the SNAT and DNAT operations, and delivers the response to the client:
    • Source IP address: AzFwPIP
    • Destination IP address: ClientPIP

In this design, Azure Firewall inspects both incoming connections from the public internet, and outbound connections from the application subnet VM by using the UDR.

  • The IP address 192.168.100.7 is one of the instances the Azure Firewall service deploys under the covers, here with the front-end IP address 192.168.100.4. These individual instances are normally invisible to the Azure administrator. But noticing the difference is useful in some cases, such as when troubleshooting network issues.

  • If traffic comes from an on-premises virtual private network (VPN) or Azure ExpressRoute gateway instead of the internet, the client starts the connection to the VM's IP address. It doesn't start the connection to the firewall's IP address, and the firewall will do no Source NAT per default.

Application Gateway only

This design covers the situation where only web applications exist in the virtual network, and inspecting outbound traffic with NSGs is sufficient to protect outbound flows to the internet.

Note

This is not a recommended design since using Azure Firewall to control outbound flows (instead of only NSGs) will prevent certain attack scenarios such as data exfiltration, where you make sure that your workloads are only sending data to an approved list of URLs.

The main difference from the previous design with only the Azure Firewall is that the Application Gateway doesn't act as a routing device with NAT. It behaves as a full reverse application proxy. That is, Application Gateway stops the web session from the client, and establishes a separate session with one of its backend servers.

The following table summarizes traffic flows:

Flow Goes through Application Gateway / WAF Goes through Azure Firewall
HTTP(S) traffic from internet/onprem to Azure Yes N/A
HTTP(S) traffic from Azure to internet/onprem No N/A
Non-HTTP(S) traffic from internet/onprem to Azure No N/A
Non-HTTP(S) traffic from Azure to internet/onprem No N/A

The following packet walk example shows how a client accesses the VM-hosted application from the public internet.

Application Gateway only

  1. The client starts the connection to the public IP address of the Azure Application Gateway:
    • Source IP address: ClientPIP
    • Destination IP address: AppGwPIP
  2. The Application Gateway instance that receives the request stops the connection from the client, and establishes a new connection with one of the back ends. The back end sees the Application Gateway instance as the source IP address. The Application Gateway inserts an X-Forwarded-For HTTP header with the original client IP address.
    • Source IP address: 192.168.200.7 (the private IP address of the Application Gateway instance)
    • Destination IP address: 192.168.1.4
    • X-Forwarded-For header: ClientPIP
  3. The VM answers the application request, reversing source and destination IP addresses. The VM already knows how to reach the Application Gateway, so doesn't need a UDR.
    • Source IP address: 192.168.1.4
    • Destination IP address: 192.168.200.7
  4. Finally, the Application Gateway instance answers the client:
    • Source IP address: AppGwPIP
    • Destination IP address: ClientPIP

Azure Application Gateway adds metadata to the packet HTTP headers, such as the X-Forwarded-For header containing the original client's IP address. Some application servers need the source client IP address to serve geolocation-specific content, or for logging. For more information, see How an application gateway works.

  • The IP address 192.168.200.7 is one of the instances the Azure Application Gateway service deploys under the covers, here with the front-end IP address 192.168.200.4. These individual instances are normally invisible to the Azure administrator. But noticing the difference is useful in some cases, such as when troubleshooting network issues.

  • The flow is similar if the client comes from an on-premises network over a VPN or ExpressRoute gateway. The difference is the client accesses the private IP address of the Application Gateway instead of the public address.

Firewall and Application Gateway in parallel

Because of its simplicity and flexibility, running Application Gateway and Azure Firewall in parallel is often the best scenario.

Implement this design if there's a mix of web and non-web workloads in the virtual network. Azure WAF protects inbound traffic to the web workloads, and the Azure Firewall inspects inbound traffic for the other applications. The Azure Firewall will cover outbound flows from both workload types.

The following table summarizes the traffic flows for this scenario:

Flow Goes through Application Gateway / WAF Goes through Azure Firewall
HTTP(S) traffic from internet/onprem to Azure Yes No
HTTP(S) traffic from Azure to internet/onprem No Yes
Non-HTTP(S) traffic from internet/onprem to Azure No Yes
Non-HTTP(S) traffic from Azure to internet/onprem No Yes

This design gives much more granular egress filtering than NSGs. If applications need connectivity to a specific Azure Storage Account, you can use fully qualified domain name (FQDN)-based filters. With FQDN-based filters, applications aren't sending data to rogue storage accounts. That scenario couldn't be prevented just by using NSGs. This design is often used where outbound traffic requires FQDN-based filtering. One example situation is when limiting egress traffic from an Azure Kubernetes Services cluster.

The following diagram illustrates the traffic flow for inbound connections from an outside client:

Application Gateway and Azure Firewall in parallel, ingress flow

The following diagram illustrates the traffic flow for outbound connections from the network VMs to the internet. One example is to connect to backend systems or get operating system updates:

Application Gateway and Azure Firewall in parallel, egress flow

The packet flow steps for each service are the same as in the previous standalone design options.

Application Gateway before Firewall

In this option, inbound web traffic goes through both Azure Firewall and WAF. The WAF provides protection at the web application layer. Azure Firewall acts as a central logging and control point, and it inspects traffic between the Application Gateway and the backend servers. The Application Gateway and Azure Firewall aren't sitting in parallel, but one after the other.

With Azure Firewall Premium, this design can support end-to-end scenarios, where the Azure Firewall applies TLS inspection to do IDPS on the encrypted traffic between the Application Gateway and the web backend.

This design is appropriate for applications that need to know incoming client source IP addresses, for example to serve geolocation-specific content or for logging. Azure Firewall SNATs the incoming traffic, changing the original source IP address. Application Gateway in front of Azure Firewall captures the incoming packet's source IP address in the X-forwarded-for header, so the web server can see the original IP address in this header. For more information, see How an application gateway works.

The following table summarizes the traffic flows for this scenario:

Flow Goes through Application Gateway / WAF Goes through Azure Firewall
HTTP(S) traffic from internet/onprem to Azure Yes Yes
HTTP(S) traffic from Azure to internet/onprem No Yes
Non-HTTP(S) traffic from internet/onprem to Azure No Yes
Non-HTTP(S) traffic from Azure to internet/onprem No Yes

For web traffic from on-premises or internet to Azure, the Azure Firewall will inspect flows that the WAF has already allowed. Depending on whether the Application Gateway encrypts backend traffic (traffic from the Application Gateway to the application servers), you'll have two different potential scenarios:

  1. The Application Gateway encrypts traffic following zero-trust principles (End-to-End TLS encryption), and the Azure Firewall will receive encrypted traffic. Still, Azure Firewall Standard will be able to apply inspection rules, such as L3/L4 filtering in network rules, or FQDN filtering in application rules using the TLS Server Name Indication (SNI) header. Azure Firewall Premium will provide deeper visibility with IDPS, such as URL-based filtering.
  2. If the Application Gateway is sending unencrypted traffic to the application servers, the Azure Firewall will see inbound traffic in clear text. TLS inspection isn't needed in the Azure Firewall.
  3. If IDPS is enabled in the Azure Firewall, it will verify that the HTTP Host header matches the destination IP. With that purpose, it will need name resolution for the FQDN that's specified in the Host header. This name resolution can be achieved with Azure DNS Private Zones and the default Azure Firewall DNS settings using Azure DNS. It can also be achieved with custom DNS servers that need to be configured in the Azure Firewall settings. (For more information, see Azure Firewall DNS Settings.) If there isn't administrative access to the Virtual Network where the Azure Firewall is deployed, the latter method is the only possibility. One example is with Azure Firewalls deployed in Virtual WAN Secured Hubs.

For the rest of the flows (inbound non-HTTP(S) traffic and any outbound traffic), the Azure Firewall will provide IDPS inspection and TLS inspection where appropriate. It also provides FQDN-based filtering in network rules based on DNS.

Application Gateway before Azure Firewall

Network traffic from the public internet follows this flow:

  1. The client starts the connection to the public IP address of the Azure Application Gateway:
    • Source IP address: ClientPIP
    • Destination IP address: AppGwPIP
  2. The Application Gateway instance stops the connection from the client, and establishes a new connection with one of the back ends. The UDR to 192.168.1.0/24 in the Application Gateway subnet forwards the packet to the Azure Firewall, while preserving the destination IP to the web application:
    • Source IP address: 192.168.200.7 (private IP address of the Application Gateway instance)
    • Destination IP address: 192.168.1.4
    • X-Forwarded-For header: ClientPIP
  3. Azure Firewall doesn't SNAT the traffic, because the traffic is going to a private IP address. It forwards the traffic to the application VM if rules allow it. For more information, see Azure Firewall SNAT.
    • Source IP address: 192.168.200.7 (the private IP address of the Application Gateway instance)
    • Destination IP address: 192.168.1.4
    • X-Forwarded-For header: ClientPIP
  4. The VM answers the request, reversing source and destination IP addresses. The UDR to 192.168.200.0/24 captures the packet sent back to the Application Gateway and redirects it to Azure Firewall, while preserving the destination IP toward the Application Gateway.
    • Source IP address: 192.168.1.4
    • Destination IP address: 192.168.200.7
  5. Here again the Azure Firewall doesn't SNAT the traffic, since it's going to a private IP address, and forwards the traffic to the Application Gateway.
    • Source IP address: 192.168.1.4
    • Destination IP address: 192.168.200.7
  6. Finally, the Application Gateway instance answers the client:
    • Source IP address: AppGwPIP
    • Destination IP address: ClientPIP

Outbound flows from the VMs to the public internet go through Azure Firewall, as defined by the UDR to 0.0.0.0/0.

Application Gateway after Firewall

This design lets Azure Firewall filter and discard malicious traffic before it reaches the Application Gateway. For example, it can apply features like threat intelligence-based filtering. Another benefit is that the application gets the same public IP address for both inbound and outbound traffic.

There's limited benefit in this scenario, because Azure Firewall will only see encrypted traffic going to the Application Gateway. There might be scenarios where this design is preferred. One case is if another WAF is earlier in the network (for example, with Azure Front Door). Or the design is preferred if many public IP addresses are required.

The following table summarizes the traffic flows for this scenario:

Flow Goes through Application Gateway / WAF Goes through Azure Firewall
HTTP(S) traffic from internet/onprem to Azure Yes Yes (see below)
HTTP(S) traffic from Azure to internet/onprem No Yes
Non-HTTP(S) traffic from internet/onprem to Azure No Yes
Non-HTTP(S) traffic from Azure to internet/onprem No Yes

For inbound HTTP(S) traffic, the Azure Firewall would typically not decrypt traffic. It would instead apply IDPS policies that don't require TLS inspection, like IP-based filtering or using HTTP headers.

The application can't see the original source IP address of the web traffic; the Azure Firewall SNATs the packets as they come in to the virtual network. To avoid this problem, use Azure Front Door in front of the firewall. Azure Front Door injects the client's IP address as an HTTP header before it enters the Azure virtual network.

Application Gateway after Azure Firewall

Network traffic from the public internet follows this flow:

  1. The client starts the connection to the public IP address of the Azure Firewall:
    • Source IP address: ClientPIP
    • Destination IP address: AzFWPIP
  2. The Azure Firewall DNATs the web port, usually TCP 443, to the private IP address of the Application Gateway instance. Azure Firewall also SNATs when doing DNAT. For more information, see Azure Firewall known issues:
    • Source IP address: 192.168.100.7 (the private IP address of the Azure Firewall instance)
    • Destination IP address: 192.168.200.4
  3. The Application Gateway establishes a new session between the instance handling the connection and one of the backend servers. The original IP address of the client isn't in the packet:
    • Source IP address: 192.168.200.7 (the private IP address of the Application Gateway instance)
    • Destination IP address: 192.168.1.4
    • X-Forwarded-For header: 192.168.100.7
  4. The VM answers the Application Gateway, reversing source and destination IP addresses:
    • Source IP address: 192.168.1.4
    • Destination IP address: 192.168.200.7
  5. The Application Gateway replies to the SNAT source IP address of the Azure Firewall instance. Even if the connection is coming from a specific Application Gateway instance like .7, Azure Firewall sees the internal IP address of the Application Gateway .4 as the source IP:
    • Source IP address: 192.168.200.4
    • Destination IP address: 192.168.100.7
  6. Finally, Azure Firewall undoes SNAT and DNAT and answers the client:
    • Source IP address: AzFwPIP
    • Destination IP address: ClientPIP

Even if the Application Gateway has no listeners configured for applications, it still needs a public IP address so Microsoft can manage it.

Note

A default route to 0.0.0.0/0 in the Application Gateway subnet pointing to the Azure Firewall is not supported, since it would break the control plane traffic required for the correct operation of the Azure Application Gateway.

On-premises clients

The preceding designs all show application clients coming from the public internet. On-premises networks also access applications. Most of the preceding information and traffic flows are the same as for internet clients, but there are some notable differences:

  • A VPN gateway or ExpressRoute gateway sits in front of Azure Firewall or Application Gateway.
  • WAF uses the private IP address of the Application Gateway.
  • Azure Firewall doesn't support DNAT for private IP addresses. That's why you must use UDRs to send inbound traffic to Azure Firewall from the VPN or ExpressRoute gateways.
  • Make sure to verify caveats around forced tunneling for the Azure Application Gateway and for the Azure Firewall. Even if your workload doesn't need outbound connectivity to the public internet, you can't inject a default route like 0.0.0.0/0 for the Application Gateway that points to the on-premises network, or you'll break control traffic. For Azure Application Gateway, the default route needs to point to the public internet.

The following diagram shows the Azure Application Gateway and Azure Firewall parallel design. Application clients come from an on-premises network connected to Azure over VPN or ExpressRoute:

Hybrid design with VPN or ExpressRoute gateway

Even if all clients are located on-premises or in Azure, Azure Application Gateway and Azure Firewall both need to have public IP addresses. The public IP addresses allow Microsoft to manage the services.

Hub and spoke topology

The designs in this article still apply in a hub and spoke topology. Shared resources in a central hub virtual network connect to applications in separate spoke virtual networks through virtual network peerings.

Hybrid design with VPN/ER Gateway and hub and spoke

Some considerations for this topology include:

  • The Azure Firewall is deployed in the central hub virtual network. Application teams often manage components such as Azure Application Gateways or Azure API Management gateways, though. These components are deployed in the spoke virtual networks.
  • Pay special attention to UDRs in the spoke networks: When an application server in a spoke receives traffic from a specific Azure Firewall instance, like the 192.168.100.7 address in the previous examples, it should send return traffic back to the same instance. If a UDR in the spoke sets the next hop of traffic addressed to the hub to the Azure Firewall IP address (192.168.100.4 in the diagrams above), return packets might end up on a different Azure Firewall instance, causing asymmetric routing. Make sure that if you have UDRs in the spoke VNets to send traffic to shared services in the hub through the Azure Firewall, these UDRs don't include the prefix of the Azure Firewall subnet.
  • The previous recommendation applies equally to the Application Gateway subnet and any other Network Virtual Appliances or reverse proxies that might be deployed in the hub VNet.
  • You can't set the next hop for the Application Gateway or Azure Firewall subnets through static routes with a next hop type of Virtual Network. This next hop type is only valid in the local VNet and not across VNet peerings. For more information about user-defined routes and next hop types, see Virtual network traffic routing.

The diagram below shows how a spoke sends back SNATted traffic back to the ALB of an Azure Firewall. This setup causes asymmetric routing:

Asymmetric routing in hub and spoke

To solve this problem, define UDRs in the spoke without the Azure Firewall subnet but with only the subnets where the shared services are located. In the example, the correct UDR in the spoke should only contain 192.168.1.0/24. It shouldn't contain the whole 192.168.0.0/16, as marked in red.

Integration with other Azure products

You can integrate Azure Firewall and Azure Application Gateway with other Azure products and services.

API Management Gateway

Integrate reverse proxy services like API Management gateway into the previous designs to provide functionality like API throttling or authentication proxy. Integrating an API Management gateway doesn't greatly alter the designs. The main difference is that instead of the single Application Gateway reverse proxy, there are two reverse proxies chained behind each other.

For more information, see the Design Guide to integrate API Management and Application Gateway in a virtual network and the application pattern API Gateways for Microservices.

Azure Kubernetes Service

For workloads running on an AKS cluster, you can deploy Azure Application Gateway independently of the cluster. Or you can integrate it with the AKS cluster using the Azure Application Gateway Ingress Controller. When configuring certain objects at the Kubernetes levels (such as services and ingresses), the Application Gateway automatically adapts without needing extra manual steps.

Azure Firewall plays an important role in AKS cluster security. It offers the required functionality to filter egress traffic from the AKS cluster based on FQDN, not just IP address. For more information, see Control egress traffic for AKS cluster nodes.

When you combine Application Gateway and Azure Firewall to protect an AKS cluster, it's best to use the parallel design option. The Application Gateway with WAF processes inbound connection requests to web applications in the cluster. Azure Firewall permits only explicitly allowed outbound connections.

Azure Front Door

Azure Front Door functionality partly overlaps with Azure Application Gateway. For example, both services offer web application firewalling, SSL offloading, and URL-based routing. One main difference is that while Azure Application Gateway is inside a virtual network, Azure Front Door is a global, decentralized service.

You sometimes can simplify virtual network design by replacing Application Gateway with a decentralized Azure Front Door. Most designs described here remain valid, except for the option of placing Azure Firewall in front of Azure Front Door.

An interesting use case is using Azure Firewall in front of Application Gateway in your virtual network. As described earlier, the X-Forwarded-For header injected by the Application Gateway will contain the firewall instance's IP address, not the client's IP address. A workaround is to use Azure Front Door in front of the firewall to inject the client's IP address as a X-Forwarded-For header before the traffic enters the virtual network and hits the Azure Firewall.

For more information about the differences between the two services, or when to use each one, see Frequently Asked Questions for Azure Front Door.

Other network virtual appliances

Microsoft products aren't the only choice to implement web application firewall or next-generation firewall functionality in Azure. A wide range of Microsoft partners provide network virtual appliances (NVAs). The concepts and designs are essentially the same as in this article, but there are some important considerations:

  • Partner NVAs for next-generation firewalling may offer more control and flexibility for NAT configurations unsupported by the Azure Firewall. Examples include DNAT from on-premises or DNAT from the internet without SNAT.
  • Azure-managed NVAs (like Application Gateway and Azure Firewall) reduce complexity, compared to NVAs where users need to handle scalability and resiliency across many appliances.
  • When using NVAs in Azure, use active-active and autoscaling setups, so these appliances aren't a bottleneck for applications running in the virtual network.

Next steps

Learn more about the component technologies:

Explore related architectures: