You dont have javascript enabled! Please enable it!

3 Steps: Deploy Application Gateway in Front of Azure Firewall

8 Min. Read

Network security is of utmost importance in today’s rapidly evolving digital landscape. Organizations need to protect their applications and data from potential threats while ensuring a seamless user experience.

Microsoft Azure offers robust solutions to address these concerns. In this article, we will explore how to set up an Application Gateway in front of the Azure Firewall to achieve enhanced security and optimized application delivery.

Introduction

To ensure the security of Azure application workloads, it is essential to implement protective measures, including authentication and encryption, within the applications. Additionally, it is advisable to incorporate security layers into the virtual networks (VNets) that house these applications. These security layers serve to safeguard the inbound flows of the applications, preventing unauthorized access. Moreover, they restrict outbound flows to the internet solely to the endpoints necessary for the proper functioning of the application.

Setting up an Azure Application Gateway in front or before Azure Firewall is a strategic decision to protect your web applications and enhance their performance. In this configuration, incoming web traffic is routed through both Azure Firewall and WAF (Web Application Firewall).

The WAF is responsible for safeguarding the web application layer, while Azure Firewall serves as a centralized logging and control point, analyzing the traffic between the Application Gateway and your backend servers. It’s important to note that the Application Gateway and Azure Firewall are not running in parallel; rather, they are sequentially positioned one after the other in the traffic flow as shown in the diagram below.

Azure Application Gateway before Azure Firewall
Azure Application Gateway before Azure Firewall

This architecture is well-suited for applications requiring knowledge of incoming client source IP addresses, such as serving geolocation-specific content or enabling logging. With the Application Gateway positioned ahead of Azure Firewall, the incoming packet’s source IP address is recorded in the X-forwarded-for header. As a result, the web server can see the original IP address through this header. For further details, you can refer to the information on how an application gateway works.

Prerequisites

To follow this article, you need to have the following:

1) Azure subscription – If you don’t have an Azure subscription, you can create a free one here.

2) You need two static public IP addresses with Standard SKU, one for the Application Gateway and one for Azure Firewall – you can create new public IPs by running the following Azure CLI commands:

az network public-ip create -n AppGWPIP -g resourceGroupName --allocation-method Static --sku Standard

az network public-ip create -n AzFWPIP -g resourceGroupName --allocation-method Static --sku Standard

3) Application Gateway v2 SKU up and running (Standard or WAF) – If you don’t have an Application Gateway, you can follow this tutorial to create an App Gateway.

4) Azure Firewall up and running (Standard or Premium) – If you don’t have an Azure Firewall, you can follow this tutorial to deploy Azure Firewall.

5) You need an Azure virtual machine (Windows or Linux) – If you don’t have a VM deployed yet, you can follow this tutorial to create a VM.

In this example, all resources are provisioned in the same virtual network. Assuming you have all the prerequisites in place, take the following steps:

Step 1: Create UDR for the App Gateway Subnet

First, you need to create and configure a user-defined route (UDR) table and then apply (associate) it to the Application Gateway subnet. A user-defined route (UDR) is a static route that overrides Azure’s default system routes or adds a route to a subnet’s route table.

// See Also: Step-by-Step how to create a custom routing table and user-defined routes (UDRs).

App Gateway Route Table Overview
App Gateway Route Table Overview

This route indicates that all traffic coming into the App Gateway which is destined for the back-end VM (virtual subnet 10.9.26.0/24), must go to the private IP address of Azure Firewall (Virtual appliance). In this example, the next hop IP address of the Azure Firewall is 10.9.24.4.

App Gateway Route Table Configuration
App Gateway Route Table Configuration

Then, you associate this route table to the Application Gateway subnet as shown in the figure below.

App Gateway Route Table Subnets
App Gateway Route Table Subnets

Step 2: Create UDR for the VM Subnet

Next, you need to create two user-defined routes (UDRs) tables, which is a routes that will apply (associate) to the back-end VM subnet.

// See Also: Step-by-Step how to create a custom routing table and user-defined routes (UDRs).

VM Route Table Overview
VM Route Table Overview

The first one is a route that indicates that all traffic going out (0.0.0.0/0) from the back-end VM (virtual subnet 10.9.26.0/24) must go to the private IP address of Azure Firewall (Virtual appliance). In this example, the next hop IP address of the Azure Firewall is 10.9.24.4.

VM Route Table Configuration (0.0.0.0/0)
VM Route Table Configuration (0.0.0.0/0)

And the second one is a UDR to 10.9.27.0/24 (Application Gateway subnet) that captures the packet sent back to the Application Gateway and redirects it to Azure Firewall.

VM Route Table Configuration (10.9.27.0/24)
VM Route Table Configuration (10.9.27.0/24)

Then, you associate this custom route table to the back-end VM (virtual subnet) as shown in the figure below including the Network Security Group (NSG).

VM Route Table Subnets
VM Route Table Subnets

If we check the Effective routes for the Network Interface of the back-end VM, we can verify that the Source is the user-defined route, the destination Address Prefix, and the Next Hop IP Address for the Azure Firewall.

You can run the commands below in the Azure Cloud Shell, or by running the Az PowerShell module from your computer:

Get-AzEffectiveRouteTable `
   -NetworkInterfaceName "NIC-Name" `
   -ResourceGroupName "RG-Name" `
  | Where-Object {$_.Source -eq "User"} `
  | Format-Table Source, State, AddressPrefix, NextHopType, NextHopIpAddress

The Network Interface Name and the Resource Group Name are blurred for obvious reasons.

Verify effective routes
Verify effective routes

Step 3: Azure Firewall Rules

Now on the Azure Firewall side, we have an Azure Firewall policy configured and the Firewall is enabled on the virtual network. In this example, all resources are deployed in the same virtual network.

In this example, we have two Network rules configured as a rule collection group, which allow the Application Gateway private subnet (10.9.27.0/24) to access the destination back-end (Destination) VM at ports 80 and 443. This step is important, the Source must be the entire private subnet of the Application Gateway because it will use a different private IP address from one of the instances.

You can change the Action between Allow and Deny.

Firewall Policy Network Rules
Firewall Policy Network Rules

Last, make sure to enable Diagnostic settings for the Azure Firewall and send the logs (Azure Firewall Network Rule, Azure Firewall Application Rule, Azure Firewall Nat Rule, Azure Firewall Fat Flow Log, and Azure Firewall Flow Trace Log) to the Log Analytics workspace.

Azure Firewall | Diagnostic settings
Azure Firewall | Diagnostic settings

Then you can verify from logs that packets are indeed sent and filtered by the Azure Firewall, and this will also help you to troubleshoot if needed.

The following KQL query will show the Azure Application Gateway (Source private IP instances), the back-end VM (Destination IP, Port, Protocol), and the Action (Allow or Deny):

AzureDiagnostics
| where DestinationIp_s == "10.9.26.4" and DestinationPort_d in ("80", "443")
| project TimeGenerated, SourceIP, DestinationIp_s, DestinationPort_d, Protocol_s, Action_s, RuleCollectionGroup_s, RuleCollection_s, Rule_s, Policy_s
| sort by TimeGenerated desc
Verify Traffic Logs Application Gateway before Azure Firewall
Verify Traffic Logs Application Gateway before Azure Firewall

That’s it there you have it!

How it Works…

The incoming HTTP(S) connections from the Internet, will be directed to the public IP address of the Application Gateway, while HTTP(S) connections from Azure or on-premises will be directed to the private IP address. The Application Gateway’s User-Defined Routes (UDRs) will ensure that these packets are routed through the Azure Firewall.

The network traffic from the public internet follows this workflow:

Network Traffic Workflow
Network Traffic Workflow

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) Next, the request to the Application Gateway public IP is distributed to the back-end instances of the gateway, in this case, 10.9.27.4 and 10.9.27.6. The Application Gateway instance stops the connection from the client and establishes a new connection with one of the back ends. The first UDR to 10.9.26.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: 10.9.27.4/10.9.27.6 (private IP address of one of the Application Gateway instances)
  • Destination IP address: 10.9.26.4 (private IP address of the back-end VM)
  • X-Forwarded-For header: ClientPIP

3) Next, 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 your Network rules allow it. However, if the traffic hits an Application rule in the firewall, the workload will see the source IP address of the specific firewall instance that processed the packet, since the Azure Firewall will proxy the connection:

  • Source IP address if the traffic is allowed by an Azure Firewall network rule: 10.9.27.4/10.9.27.6 (private IP address of one of the Application Gateway instances)
  • Source IP address if the traffic is allowed by an Azure Firewall application rule: 10.9.24.4/10.9.24.6 (private IP address of one of the Azure Firewall instances)
  • Destination IP address: 10.9.26.4 (private IP address of the back-end VM)
  • X-Forwarded-For header: ClientPIP

4) Next, the back-end VM answers the request, reversing source and destination IP addresses. The second UDR to 10.9.27.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: 10.9.26.4 (private IP address of the back-end VM)
  • Destination IP address: 10.9.27.4/10.9.27.6 (private IP address of one of the Application Gateway instances)

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: 10.9.26.4 (private IP address of the back-end VM)
  • Destination IP address: 10.9.27.4/10.9.27.6 (private IP address of one of the Application Gateway instances)

6) Finally, the Application Gateway instance answers the client over its public IP address:

  • Source IP address: AppGwPIP
  • Destination IP address: ClientPIP

The outbound flows from the back-end VMs to the public internet go through Azure Firewall, as defined by the third UDR to 0.0.0.0/0.

FAQs

Can I use multiple backend pools in an Application Gateway?

Yes, Azure Application Gateway supports multiple backend pools, allowing you to distribute traffic across different sets of backend servers based on your requirements.

Does Azure Firewall provide advanced threat protection?

Yes, Azure Firewall includes Threat Intelligence, which uses threat intelligence feeds to identify and block malicious IPs and domains. It enhances the security of your virtual network.

Can I use Azure Firewall without an Application Gateway?

Yes, you can use Azure Firewall independently to control outbound internet access for resources in your virtual network.

What is the role of the frontend IP in an Application Gateway?

The frontend IP configuration defines the public IP address and port that the Application Gateway listens on to receive incoming traffic.

Does Azure Firewall support Network Address Translation (NAT)?

Yes, Azure Firewall supports Destination Network Address Translation (DNAT) and Source Network Address Translation (SNAT).

DNAT translates inbound internet network traffic to its public IP address and filters it to the private IP addresses on your virtual networks or to another public IP. This is accomplished using DNAT (Destination Network Address Translation) rules in the Azure Firewall Policy.

With SNAT, Azure Firewall performs Source Network Address Translation (SNAT) for all destination public IP addresses processed by network rules. However, Azure Firewall does not SNAT if the destination is a private IP range by IANA RFC 1918. For application rules traffic, Azure Firewall is always SNAT regardless of the settings you configure.

Can I use custom domain names with the Application Gateway?

Yes, you can use custom domain names by configuring the required SSL certificates and frontend listeners accordingly.

Conclusion

In this article, we showed you how to set up Azure Application Gateway before Azure Firewall, in this scenario, the packets coming to Application Gateway will be forwarded to the Firewall for filtering and controlling, and then sent to the back-end VM. The VM responds with the requested data to the client from the original route.

The key points for this architecture to work are the following:

  1. Create a user-defined route (UDR) and apply it to the Application Gateway subnet, then point it to the Azure Firewall private IP address.
  2. Create a user-defined route (UDR) and apply it to the VM subnet, then point it to the Azure Firewall private IP address.
  3. Configure Azure Firewall network/application rules.
  4. (Recommended) Enable Diagnostic settings for Azure Firewall to verify and troubleshoot.

Setting up an Application Gateway in front of Azure Firewall is a crucial step in strengthening your network security and ensuring optimal performance for your applications.

By following the outlined steps and best practices, you can create a secure and efficient environment for your users and data. Remember to monitor and update your configurations regularly to stay ahead of potential threats and ensure seamless operations.

> Learn more about Azure Firewall and Application Gateway for virtual networks.

__
Thank you for reading my blog.

If you have any questions or feedback, please leave a comment.

-Charbel Nemnom-

Photo of author
About the Author
Charbel Nemnom
Charbel Nemnom is a Senior Cloud Architect with 20+ years of IT experience. As a Swiss Certified ICT Security Expert, CCSP, CISM, MVP, and MCT, he excels in optimizing mission-critical enterprise systems. His extensive practical knowledge spans complex system design, network architecture, business continuity, and cloud security, establishing him as an authoritative and trustworthy expert in the field. Charbel frequently writes about Cloud, Cybersecurity, and IT Certifications.
Previous

Conquer The AI-050 Course and Revolutionize Your Skills in Developing Generative AI Solutions With Azure OpenAI Service!

Easy Steps to Install a Windows Service

Next

4 thoughts on “3 Steps: Deploy Application Gateway in Front of Azure Firewall”

Leave a comment...

  1. Thanks for sharing this blog, Will it make any difference if we enabled WAF in the application gateway itself to secure our web traffic.

  2. Hello Yashpal, thanks for the comment and feedback!
    Yes, you can enable WAF in the application gateway itself to secure your web traffic.
    If your application is deployed to the web, enabling Web Application Firewall will protect you from Layer 7, application attacks.
    I mentioned in the prerequisites section that you should have an Application Gateway v2 SKU up and running (Standard or with WAF).
    Hope it helps!

  3. How does the Azure firewall do threat inspection of malicious IPs when the source IPs are the Application Gateway and not the actual external client IP?

    Is the Azure firewall also looking at the x-forwarded-for?

  4. Hello Jack, thanks for the comment and the great question!
    Yes, both HTTP and HTTPS protocols (with TLS inspection) are always filled by Azure Firewall with an XFF (X-Forwarded-For) header equal to the original source IP address.
    In the scenario described above where the Application Gateway is positioned ahead of Azure Firewall, the external client IP will be preserved and included in the X-Forwarded-For header.
    Hope it helps!

Let me know what you think, or ask a question...

error: Alert: The content of this website is copyrighted from being plagiarized! You can copy from the 'Code Blocks' in 'Black' by selecting the Code. Thank You!