Deploying a Wildcard Azure Application Gateway using Powershell
What is Azure Application Gateway?
Azure Application Gateway has been around for quite a few years now. Over the past few years, we have seen it change from the original Standard (V1) without any Web Application Firewall functionality to the most recent Standard (V2) with or without WAF functionality. The v2 version has been released on April 30th 2019 so it probably has replaced most of your V1’s by now (or if you want to start fresh, the V2 is probably the way forward)
How does an Application Gateway work?
Just as a reminder, how does an Azure Application Gateway exactly work:
As illustrated in the image above, you can place an Azure Application Gateway between (web)clients — for example users that want to connect to your website — and your backend server(s). Traditional load balancers operate at the transport layer (OSI layer 4 — TCP and UDP) and route traffic based on source IP address and port, to a destination IP address and port.
Application Gateway can make routing decisions based on additional attributes of an HTTP request, for example URI path or host headers. For example, you can route traffic based on the incoming URL. So if /images is in the incoming URL, you can route traffic to a specific set of servers (known as a pool) configured for images. If /video is in the URL, that traffic is routed to another pool that’s optimized for videos.
This type of routing is known as application layer (OSI layer 7) load balancing. Azure Application Gateway can do URL-based routing and more. If you want to know more about all features an application has, please check out this site
Now introducing: Wildcard Application Gateway
So, for those of you that have been deploying Application Gateways in the past, whether it be through the use of ARM templates, Azure CLI or Powershell, will probably know that the process of deploying an AGW is quite cumbersome, especially when you want to define multiple listeners and/or backend HTTP settings. Personally, I have been deploying Application Gateways in the past that consisted of 15 listeners and subsequent backend settings, all ending on the same domainname.
For example:
www.contoso.com;
Contoso.com;
My.contoso.com;
Etc.
The problem with a setup like this is that it was quite a lot of work creating the listeners, associating them to a rule which in turn is associated to a backend and HTTP setting. And you had to it for every single hostname you wanted to configure, despite the fact that they all shared the same domain.
But since the 20th of July 2020, Microsoft has announced that they will now also support the option to define wildcard hostnames in a multi-site listener. And you can use up to 5 unique hostnames per listener. Isn’t that great?
So how that exactly works is pictured below:
As you can see in the above image, there are multiple ‘multi-site’ listeners configured on this application gateway:
— *.contoso.com, *.fabrikam.*
— *.contos-*, frabrikam-??.com
These listeners can then be routed to the same or different backend pools.
So, using a wildcard character in the host name, you can match multiple host names in a single listener. For example, *.contoso.com can match with ecom.contoso.com, b2b.contoso.com as well as customer1.b2b.contoso.com and so on. Using an array of host names, you can configure more than one host name for a listener, to route requests to a backend pool. For example, a listener can contain contoso.com, fabrikam.com which will accept requests for both the host names.
The caveats of wildcard listeners
Since wildcard listeners are currently still in preview, there are some considerations and limitations to take into account:
1. This feature is in preview and is available only for Standard_v2 and WAF_v2 SKU of Application Gateway.
2. This feature is currently available only through Azure PowerShell and Azure CLI. Portal support is coming soon. Please note that since portal support is not fully available, if you are using only the HostNames parameter, the listener will appear as a Basic listener in the portal and the Host name column of the listener list view will not show the host names that are configured. For any changes to a wildcard listener, make sure you use Azure PowerShell or CLI until it’s supported in the portal. I will share some screenshots regarding this further down this blog.
3. You cannot create a redirection rule with a target listener which uses wildcard or multiple host names. So you cannot create a HTTP to HTTPS redirect like you can in a non-wildcard listener setup.
4. For backend health check, you cannot associate multiple custom probes per HTTP settings. Instead, you can probe one of the websites at the backend or use “127.0.0.1” to probe the localhost of the backend server. However, when you are using wildcard or multiple host names in a listener, the requests for all the specified domain patterns will be routed to the backend pool depending on the rule type (basic or path-based).
5. You cannot use a regular expression to mention the host name. You can only use wildcard characters like asterisk (*) and question mark (?) to form the host name pattern.
6. If multiple host names are mentioned in the same listener, you must upload a SAN certificate (Subject Alternative Names) with the CNs matching the host names mentioned.
7. If it is a wildcard hostname like *.contoso.com, you must upload a wildcard certificate with CN like *.contoso.com
Enough with the theory! How do I deploy?
As mentioned before, at the time of writing this blog, you can either user Powershell or Azure CLI.
I have build a powershell example that will do the following:
1. Find the approriate VNET and Subnet to deploy the AGW into.
2. Create a public IP address to be used by the AGW
3. Create IPconfigurations for Gateway and the frontend
4. Create backend-pools
5. Create listeners and routing rules
6. Create Web Application Firewall policy
7. Configure TLS policy settings
8. Create the application gateway (at this point it will be a HTTP only AGW)
Then after the AGW has been succesfully deployed, the script will add HTTPS to the application gateway:
9. Find the AGW and store it into a variable
10. Add the SSL certificate (PFX + password required) and store it into a variable
11. Add the HTTPS frontend listener port and store it into a variable
12. Get the frontend IP configuration and store it into a variable
13. Add a frontend listener (HTTPS) and store it into a variable
14. Get the backendpool and store it into a variable
15. Add Backend HTTP settings and store it into a variable
16. Tie all of the above togheter in a Routing Rule
17. Update the Application Gateway with everything created in steps 8–15.
The powershell script
Before you can run the powershell script, there are a few things you need to do:
1. Login to Azure, using powershell (login-azAccount)
2. Find the subscription that you want to deploy into (get-azSubscription)
3. Select that subscription (select-azsubscription -subscription “SUBSCRIPTIONNAME”)
4. Make sure you have the following created a VNET and Subnet in your subscription, that is capable of deploying the AGW into. For subnet sizing, using a /26 subnet is recommended as minium.
5. If you have a working VNET and subnets deployed into a resourcegroup of your choosing, fill the following parameters with the appropriate information:
— Virtual Network ResourceGroup name ($VnetRGName)
— Virtual Network Name ($VnetName)
— SubnetName ($SubnetName)
6. The rest of the variables is really up to you. Because there might be things involved like naming convention, timeout settings etc. I will not recommend anything here. My script is based upon a single wildcard listener with a single backend and some default http settings, but feel free to edit these to your liking.
7. Special attention goes out to the WAF & SSL/TLS settings. This script will enable WAF for you and it will create a WAF policy in the same resourcegroup as the Application Gateway will be deployed in. This WAF policy is then tied to the AGW. For SSL/TLS settings I’m enabling the latest pre-configured (best-practice) policysetting.
What will be the result?
Once you have run the powershell script, you will end up with a resource group that has the following resources:
1. The Application Gateway itself
2. A public IP address that is tied to the Application Gateway
3. A custom Web Application Firewall Policy that is tied to the Application Gateway
I hope this post helps you deploy and configure the Wildcard Application Gateway that you want!
Useful links:
The Powershell script at github
Microsoft documentation
