The myth of Azure Application Gateways – Part 1

Azure Application Gateways is a layer 7 reverse proxy service offered as a PaaS to general public. It supports SSL offloading, which means you can terminate your SSL connection at the Application Gateway and connect to the backend server using HTTP traffic or initiate a new SSL connection to your backend service.

This is all well and good, simple and painless if you have a single backend server with a single website. The complexity of the solution increases as the backend start leveraging more of the IIS functionalities such as Windows/NTLM authentication, SNI and host headers or various SSL certificates used for each sub-site (if you have multiple sites running on the same IIS server).

Before even starting to look at designing your Azure Application Gateway, there are few guidelines you will need to follow:

You should have an empty default site.

If using both HTTP/HTTPS protocols on any of the sub-sites, the default website should be listening on both 80 and 443.

In the case of HTTPS the default site will need to be loaded with a single SSL certificate that will primarily be used by the Application Gateway to authenticate against the server.

Not running SNI on default website.

If you are running NTLM or Windows authentication on any of the sites (except form based authentication) then you will need a site/page that allow anonymous authentication to be used for Application Gateway custom probe.

Use IP address for the backend pool rather than FQDN.

The above will save you a lot of hassle while implementing and configuring your Application Gateway to work with your backend web server.

Microsoft have fixed few issues we were experiencing recently with Application Gateways around SSL and custom probes.

There are two ways available to deploy an Application Gateway, Powershell or JSON template. The latter is preferable to ensure consistency at each deployment. This article is in two parts, in this article I will be using Powershell to deploy an Application Gateway.

Prerequisites:

SSL private key in PFX format for all sites using SSL

SSL public key in CER format for default site

IP address of the backend web server

Front and backend listening port

Site/page with anonymous access if requiring authentication

Powershell code below would deploy an Application Gateway listening on two ports (80,443). The backend consists of four sites with SNI and host headers enabled, two sites run under port 80, one of them require basic authentication. Another two sites run under port 443 bound with self-signed SSL cert for testing, one of the sites has basic authentication turned on. This would test the four common scenarios of a typical deployment.