Configure an Azure Application Gateway for Path-based URL redirection, Request Redirection, Reverse Proxy, and WAF
The goal of this article to illustrate step-by-step how to set up an Azure Application Gateway for your web services using the Azure Portal.
Reference: https://docs.microsoft.com/en-us/azure/application-gateway/create-url-route-portal
Before we begin with this tutorial, I would like to level set us with some basic understanding of the various components we will be configuring. I think it is crucial to understand what we are doing before doing it. Here are some basic questions one should know
- What is an application gateway?
- What is a reverse proxy?
3. What are the real-world use cases for Application Gateway?
4. What is the difference between HTTP and HTTPS requests?
Let’s start with a given real-world use case that I encountered in one of my projects.
We had a requirement to build a website that allows users to sign in either through an email account or their Linkedin profile. To implement an account registration from Linkedin, we have to redirect the user to the LinkedIn authorization page so that Linkedin will authenticate that user and send us back a token (basic user information). In our solution, we have provisioned an Azure App Service to host our front-end web service and another App service to host our backend web services. We implemented logic to route all default requests to our web page to land on our frontend app service, while any other requests like when a user wants to signup via LinkedIn or clicks email signup will be routed to our backend app service. In our backend app service, we have logic to handle those requests appropriately based on the URL relative path
Have you noticed a website that has this “Not Secure” tag on the left of the URL like the below screenshot? If you type the below you will see this website (my personal blog website) http://plsqlandssisheadaches.blogspot.com/
Notice that it is the HTTP protocol version for this website.
Alternatively one can get this to the website through the HTTPS protocol that is more secure https://plsqlandssisheadaches.blogspot.com/
Notice that the “Not Secure” label is gone for the same web page.
By default, if someone types in the short form of the website plsqlandssisheadaches.blogspot.com they will land on the HTTP protocol page. However, if you try a well-known website like medium.com or http://medium.com you won’t see the “Not Secure” label. Why?
This is because well-known websites have an HTTP to HTTPS URL redirection going on. Most browsers take cybersecurity seriously and will always highlight an HTTP link as “Not secure”. However, with a Request Redirection, we can ensure this does not happen. This redirection configuration can be taken care of by an Application Gateway.
Another importance of this gateway is that it will act as a firewall to prevent users from directly accessing our front end and backend app service and protect our webservers from DOS attacks and SQL injection.
What is a reverse proxy?
A reverse proxy is a server that sits in front of one or more web servers, intercepting requests from clients. With a reverse proxy, when clients send requests to the origin server of a website, those requests are intercepted at the network by the reverse proxy server. The reverse proxy server will then send requests to and receive responses from the origin server.
What is an Application Gateway?
Let’s talk about Azure Application Gateway. It is a web traffic load balancer that enables you to manage traffic to your web applications. It has many features like the below found in Azure documentation
Application Gateway includes the following features:
- Secure Sockets Layer (SSL/TLS) termination
- Autoscaling
- Zone redundancy
- Static VIP
- Web Application Firewall
- Ingress Controller for AKS
- URL-based routing
- Multiple-site hosting
- Redirection
- Session affinity
- Websocket and HTTP/2 traffic
- Connection draining
- Custom error pages
- Rewrite HTTP headers and URL
- Sizing
In this article, I will only discuss and demonstrate how to use an Application Gateway for Web-based Firewall, URL-based routing, and Redirection.
Please note for you to do this in the Azure portal there are certain gotchas that you have to be mindful of which I will highlight.
Prerequisite, you already have an Azure account, app service, or VM (ideally should be using App service) that hosts your website code. One will be your front end and another your backend.
STEP 1: Basic settings of picking a resource group, naming application gateway, and picking a VNET subnet
STEP 2: FRONT END CONFIG
This is where you pick or create the Public IP Address that will be assigned to this gateway. In this case, I picked a suggested IP Address from my test VNET
STEP 3: ADD BACKEND POOL
In this case, we will add two sample backend pools. One for the front end web service and another Backend pool for the backend web service. Note that you can have multiple web services under the same backend pool. However, I think that will be if you have a load balancing use case where you want to distribute the workload among multiple nodes of the same web service functionality.
STEP 4: ADD ROUTING RULE for HTTP OR HTTPS requests
This is the trickiest step. Beware of this bug in Microsoft Azure Portal, during this initial gateway provisioning this ability to add Path based routing rule is only available in this phase. If you didn’t configure this URL path based routing properly in this phase before Application Gateway provisioning. You won’t be able to add/change it later.
HTTP LISTENER
HTTPS LISTeNER
Let’s deep dive into the key fields and what they really mean
- Listener settings
What is Frontend-IP? This is the same Frontend-IP address that we set up in Step 2. We picked Public so this means that any client or user from public internet can access or send requests to our Application gateway and we can accept their request.
What does Protocol mean? Every request to our website (Gateway) has to be either HTTP or HTTPS. In the development environment, setting it to HTTP should be good enough. However, for the production environment we need to make sure we have two listeners one for HTTP and the other for HTTPS. HTTP is normally the default protocol is our website URL does not specify the protocol. To set up HTTPS we would need to buy a valid certificate from CA authority. Please refer to this link for more details on acquiring a domain and buying a certificate link. Also, note that the gateway only listens to request from port 80 for HTTP and port 443 for HTTPS requests. This concept of listener and port is important to understand. I tend to think of the listener as a physical Gate while the ports are different entry methods for the gate. For example, someone can enter the gate using a key, someone can use a pin code or facial recognition.
HTTP to HTTPS Redirection: Since we also want to achieve this, I would advise you to first create a routing rule for the HTTPS requests for listener in this step, then we will create another routing rule for HTTP requests this will be redirected to the HTTPS listener ( will discuss this more).
2. Backend settings
Things to note here. if you just use the first section at the top it will handle all the requests in a default manner basically no path-based routing. if you add path-based routing then It ignores whatever default setting you have on the top.
In this top section, I will pick the front end web service as my backend pool knowing that this setting is only for cosmetics and does not really do anything for us. Remember, we want to implement path-based routing.
HTTP SETTING: As I try to route the requests received from the listener by the Gateway to my backend target pools. It will need an HTTP Setting to help it function properly. This is another crucial one that you really need to learn and understand, if not your gateway won't work
This HTTP Setting solely depends on the backend targets that you trying to using in your Gateway. In our case, we are using the Azure App service which has been configured to only accept HTTPS requests. Therefore when we set up the HTTP Setting in our Gateway we must pick HTTPS backend protocol. However, if you set up your App Service to allow both HTTP and HTTPS requests then you can pick either one in your HTTP setting. By default, HTTPS goes to port 443. Since we are doing this in the development environment and we don’t have a valid certificate.
We will select “Yes” for the Use well-known CA certificate because Azure app service already has a certificate for their app service.
If your App service is setup to allow only HTTPS and you used a HTTP setting with a HTTP protocol at port 80 on your Gateway then you will get an error where the url is trying to access a HTTPS://yourwebsite.com:80 (at port 80 ), instead of port 443. I got this error. So please be careful here make sure you understand your app service well and use relative paths in your code to ensure all the requests from the website gets routed through the gateway.
Pick Override with new hostname as ‘Yes’. If you read the note by Microsoft on this setting you will understand why it is necessary. It has to deal with when we use App Service as the backend target and how difficult it is for Microsoft to resolve to the correct DNS.
Then Pick one from backend targets. Again this is another special setting for those using App Service as their backend service.
After saving the HTTP Settings. Under the Path Based Rules section Click on “Add multiple targets to create a Path-based rule”
Using a Custom Probe is optional so do as you please. I picked “No” (No custom Probe)
CONFIGURING PATH BASED ROUTING
We need to ensure our gateway is configured to ACCEPT and ROUTE all these requests. The ACCEPT of request is handled by Listener setting while the ROUTE is handled by the Path based routing rules settings in our application gateway
Editing the path based rules
I set the /* means all default requests will go to the front end. Target-name is just a name. Again as we route to a backend target (app service) we need to accompany that with the appropriate HTTP setting which in our case is the HTTPS setting since our App service is configured to only allow HTTPS requests.
The second rule is to route all /auth/linkedin URL paths to the backend web service
That is it for the HTTPS routing rule if you picked HTTPS Listener in Step 1. If you are doing this for Dev, then you can just do HTTP listener and this will be the last step for you. However, note that if someone tries to get to your Gateway (website) using HTTPS protocol they will hit an error page, because you have not configured any listener for it.
ADD REDIRECT ROUTING RULE FOR ANY HTTP REQUEST TO BE REDIRECTED TO HTTPS
SETUP HTTP LISTENER
Select HTTP, then we click Backend targets
Now click on Redirection button. In the above pick the HTTPS listener you created when you did the first routing rule above as your Target Listener. By doing this, it means that all requests to access the Gateway from HTTP will be redirected to HTTPS where all the rules will be applied accordingly.
After this setting click create Gateway.
WEB APPLICATION FIREWALL SETTING
After gateway creating you can now configure the web firewall to the appropriate setting. This is quite straightforward
TIPS
When it comes to testing your gateway
Tip1: access your gateway server using an incognito browser to avoid the cookies and see the true nature of the latest change you made
Tip 2: wait for the application gateway to finish saving new settings before testing or risk seeing the unwanted result.
Tip 3: Use custom Probe to ensure your backend app services are working properly.
Tip 4: You can make things secure by making sure the Gateway and your App services are in the same VNET and you have the right access rules to all access from the Gateway Subnet
Tip 5: Take baby steps and tinker with each setting to ensure you understand the configurations. Don’t just try your luck! Be scientific !
