Application Gateway with Public facing Web Apps

Azure Application Gateway

The most common use of Application Gateway is to expose web sites running on VM’s. I’m going to walkthrough configuring an existing App Gateway to target a Web App running on the public Azure App Service, and then securing the Web App to only take traffic from the Application Gateway. By putting an Application Gateway in front of your website, you can make use of the Web Application Firewall that it provides.

Lets start with creating the Web App. I’m using a standard ASP.NET web forms app from Visual Studio, and have tweaked the main page to output all of the HTTP headers onto the default web page so i can see what’s going on. Here’s the code needed to do that.

Once i’ve published it to Azure Web Apps, i now need to add my custom domains. This is pretty easy – with your Domain Registrar, you add a CNAME entry for the right subdomain to point to the FQDN for your web app. EG. maps to

After you’ve done this for all the subdomains you want, you come back to the Azure Portal, Verify each domain and Add each hostname in the Custom Domains section of your Web App.

At this point we’re ready to configure/create the Application Gateway. You can find several scripts here;
I can recommend the CreateAppGW-ForWebApp-v2 script because it creates the AppGW. This means that it rules out any config mistakes/issues you may have on an existing gateway. However there is a script there for when you have an existing gateway which i’ve used a couple of times.
NOTE: If you’re using a script that creates the Application Gateway, it will take over 30 minutes to provision.

After the Application Gateway has been created, you can now flip the DNS CNAME(s) to target the Application Gateway instead of the Web App directly. You should use the address associated with the Application Gateways IP address. For me, this is

Once you have made the DNS changes, and they have been acknowledged by the various DNS servers and your cache you’ll get a page that looks like this.

This just leaves the process to lockdown the Web Application to only take traffic once it’s originated from the Application Gateway.
Azure App Service Static IP Restrictions

After configuring the IP restriction with the IP address of your Application Gateway, when navigating to your Web App directly, you will be told;

This just leaves one remaining gotcha. Application Gateway only supports Dynamic Public IP Addresses. This of course means that should your Application Gateway change IP (not an expected operation, but still possible) you will need to adjust the configuration of your Web App IP Restriction.

New-AzureRmApplicationGateway : FrontendIpConfiguration /providers/Microsoft.N
fig01 of Application Gateway with SKU tier WAF can only reference a
PublicIPAddress with IpAllocationMethod as Dynamic.

Application Gateway will support a Static IP address soon, but as of the time of writing – there is only a private preview programme open for it.

Cloud Solution Architect at Microsoft in the UK.

Azure Application Gateway – solving 502 errors with httpd

I’ve recently been playing with the Application Gateway in Azure. Use case is pretty simple, serving as a simple load balancer / waf / dmz for an application that lives on some RHEL VM’s.
To Run App Gateway in its simplest configuration, you just have to;
– Create the vnet
– Create a subnet for the App Gateway (something like a /27 should do)
– Create a subnet for the VM’s
– Create the Application Gateway
– Create the VM’s (just with private ip’s)
– Add the VM’s to the backend pool
– Add an App Gateway NSG to allow port 80/443 and 65503-65534 for the health probe
– Add a VM subnet NSG to allow port 80 from the App Gateway subnet.

However, sometimes these things just don’t work and you need to fault find. The problem I had was that the gateway kept reporting a 502 error, and stating that all the nodes in the backend pool were unhealthy. This is a great article to start with, but didn’t help my problem.

What I then did was create another subnet and dropped a Windows VM jumpbox into it. From here, I could adequately browse the Linux VM’s in IE, as well as SSH onto them to check configuration from inside the same virtual network.

In the end, I created 6 different VM’s with different configuration before the problem became clear. Httpd was the problem.

OS Web server Healthy?
Windows Server 2016 IIS Yes
Ubuntu 17.04 Nginx Yes
CentOs 7 httpd No
RHEL 7.3 httpd No
RHEL 6.7 httpd No
RHEL 7.3 nginx Yes

Because all the traffic on the private IP’s worked correctly from the jumpoff box, it’s clear that it wasn’t a firewall or nic configuration problem. The one consistent issue was httpd. After trying a few different settings changes in http.conf, I found the solution.
The default welcome page was causing the probe not to work. By creating an index.html file in /var/www/html/ the health probe began reporting success.

Damn you welcome page!

Cloud Solution Architect at Microsoft in the UK.