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.
Table of Contents
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.
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 Standard3) 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.
- You need a virtual network and a dedicated subnet for the Application Gateway. For more information, please follow the instructions described here.
- Check how to configure Application Gateway including (Backend pools, Listeners, HTTP Settings, Health probe, and Routing Rules).
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.
- You need a virtual network and dedicated subnet for Azure Firewall. For more information, please follow the instructions described here.
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).
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.
Then, you associate this route table to the Application Gateway subnet as shown in the figure below.
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).
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.
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.
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).
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, NextHopIpAddressThe Network Interface Name and the Resource Group Name are blurred for obvious reasons.
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.
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.
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
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:
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 send 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:
- Create a user-defined route (UDR) and apply it to the Application Gateway subnet, then point it to the Azure Firewall private IP address.
- Create a user-defined route (UDR) and apply it to the VM subnet, then point it to the Azure Firewall private IP address.
- Configure Azure Firewall network/application rules.
- (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-
