How to configure Application Gateway before Azure Firewall to App Services

Question

Dear Microsoft community, I have an application gateway setup with WAF with app services as the backend pool targets. I have also setup access restrictions in the app service networking to only allow traffic through application gateway. Till here everything's working. I wish to add a firewall after the application gateway. I have attached a route table to the application gateway subnet. May I know what is needed to specify in routes and network rules? Haven't had any luck so far.. Thank you in advance!

Answer 1

@Martin Garrix

Welcome to the Microsoft Q&A forum.

If I have understood the question correctly you have an application gateway with azure app services as backend now you wish to add a Azure Firewall after your application gateway and you want to know which routes and network rules need to be specified.

Based on my understanding above, you can refer to this similar architecture here (added diagram as a reference)

On the Application Gateway you will have to add a route which directs the traffic to your backend pool via Azure Firewall's private IP (In this case 192.168.1.0 -> 192.168.100.4).

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. I think you will have to create a network rule in Azure Firewall allowing communication via AppGwSubnet.

Since your backend is a web app I think you can use Network routing to route the outbound traffic from the app as discussed here and you also need to allow the source ip here in your Azure Firewall for outbound connection.

Hope this helps! Please let me know if you have any additional questions. Thank you!

---

​​Please "Accept the answer" if the information helped you. This will help us and others in the community as well.

Answer 2

Hi Martin,
This is a design I regularly use and it works nicely.

Joe, the benefit is that you can apply IDPS from Azure Firewall to the traffic between the WAF and the backend. Based on recent work, I'm finding that I have to disable a lot of OWASP rules in the WAF_v2 to clean out false positives and to reduce Log Analytics costs (false positives were ~76% of the ingestion cost).

As stated above, the trick to this is routing.

Let's start with the spoke where the App Service is connected. If you are using Private Endpoint with VNet integration then the VNet integration subnet needs a route to egress the VNet with a next of the Virtual Appliance/[IP Address of Azure Firewall]. For me, that's a 0.0.0.0/0 user-defined route sending all egress traffic to the firewall.

I usually place a shared WAF in a dedicated spoke. Peering the WAF spoke with the hub creates a route from the firewall to the WAF. Otherwise (I don't recommend this in case you go with multiple hubs - long story), you can put the WAF in the hub. Either way, the firewall has a route to the WAF; this means the backend has a route to the WAF, via the firewall.

For ingress, you need to manage the routes on the WAF subnet. You will need to add two routes:

• 0.0.0.0/0 > Internet - another long story but you will want to force this route which is required for the WAF to function.
• A second route to your backend(s) with a next hop of the Azure Firewall private IP.

For the above second route, I use a prefix that includes the entire address space that can peer with the hub. That way the job is done for all potential backends.

The final pieces are security:

1. An Azure Firewall rule to allow the WAF to the backend.
2. An NSG rule on the backend subnet NSG to allow the WAF to talk to the backend.
3. Make sure that any present rules on the backend allow the WAF to talk to the backend.

Now, on to why do this.

As I said, OWASP is NOISY and you end up, even with exclusions (if they work for you) disabling a lot of scanning. If you run Azure Firewall Premium with IDPS enabled then you can scan traffic from the WAF to the backend, potentially finding things that the WAF did not find.

If you relay HTTPS from the WAF to the backend, then IDPS is pretty much useless outside of a VM-based lab - in my personal experience ... it's the firewall version of the chocolate teapot. But if you terminate SSL at the WAF and relay HTTP to the backend then IDPS is useful. So that's what I would recommend here.