Azure Front Door Advanced Configurations

Continue from the previous post, Azure Front Door Basic Walk Through, I will configure the followings on this post.

  • Restricts only AFD to your backend
  • Force HTTP to HTTPS
  • Configure your custom domain name
  • Setup HTTPS by using AFD managed SSL

In this demo, I have an Azure Frond Door and Linux client only. I have connected the AFD and Linux client already. Without further ado, let’s get started.

From my NB, I can access the client directly cause I have allowed my source IP on the client’s FW.

On the other hand, I CANNOT access the client through AFD cause it is not allowed on client’s FW.

In previous post, we talked about that AFD only works with backend with public IP address, therefore, AFD must be allowed to be able to access the client. So, let’s configure the client’s FW only accepting requests from AFD.

The key is to accept traffic from Azure Front Door’s backend IP address space or service tag and Azure’s infrastructure services only.

According to the document, let’s setup the FW as below. №3 is the key configuration to make it work.

Once done, it is verified that I can now access the client THROUGH AFD and NOT directly anymore.

When accessing the URL using HTTP, it will show Not Secure as below.

Configuring AFD redirect rule consists of two steps,

  1. Configure a redirect rule
  2. Configure a rule for HTTPS

For step 1, open routing rule configuration of AFD and modify as below.

Scroll down a bit and modify the Route type, update the configuration when done.

06 July updated:For Redirect type, it is better to choose Moved (301)

For step 2, let’s create a new rule for HTTPS.

Scroll down a bit to Route type and configure as below.

06 July updated:Depending on how your backend is serving the service. If your backend is serving http, choose HTTP only then.

Finally, add the new rule and save changes to AFD. Now try to access the url with HTTP again and you should see it is redirected to HTTPS. We can verify it from inspector mode, seeing a 302 status.

To achieve, you need to have self owned domain name. I have mine hosted on AWS Route53 and already setup a CNAME record pointing to AFD’s FQDN, which is, as below.

For my own protection, I blocked all sensitive information.

Next, setup custom domain name in AFD as below. When you input your own domain name, AFD will check it out simultaneously and tell you what to do. So make sure you have already CNAMED your domain name. Following is an EXAMPLE screen shot.

With the proper domain name configured, we need to configure a routing rule to our custom domain name next.

For simplicity, I am setting the new rule the simplest way. Only modified sections are shown.

Finally, Add the new rule and save all changes to AFD. Wait a bit for changes to take place and verify the result.

For this part, it is quite easy to setup. All you have to do is enable HTTPS for you own domain name, select TLS version and choose Certificate management type, as shown below.

Azure AFD works with DigiCert CA to validate ownership of your domain automatically, so you do not need to worry a thing. For more details, please refer here.

The TRICKY part is that for Front Door managed option, it takes from minutes to an Hour to complete, so update the settings and go get yourself a coffee ; ). For more details, please refer here.

After a while, checking back the result, we could see that it took about half an hour to success. (Yeah.. I took a five hours break… XD)

For verification, we could see that my domain is indeed running with SSL and the certificate is issued by DigiCert CA with organization registered as Microsoft.

And that’s it for today’s post. I will share more AFD configurations on next post, stay tuned!

AWS Certified SA, SysOps & Developer Associate, Alibaba Cloud certified SA. Focusing on Azure, Prometheus w/ Grafana, ELK and K8S now.