Test Azure Front Door Premium with a Private Link-enabled Azure Web Application

[Guest Aarthi795_MSFT]

Introduction:

 

If you are looking to consider using the Private Link origin feature recently introduced with Azure Front Door Standard and Premium SKUs, here is a post for you. If you are new to Azure Front Door Premium, please follow the steps here to create one using the Azure portal. It is now easier to enable a Private Link for an origin on an Azure Front Door Premium and to be able to test if the Private Link is being used and working. If you would like to learn more about the Private Link feature with Azure Front Door Premium, please feel free to check this Guide.

 

 

 

A very common scenario, in this security-aware world, is one where we would want to host our cloud-based applications behind a layer 7 load balancer such as Azure Front Door, where the Premium and Standard SKUs have recently started to support Private Link origins for accessing web applications with private IP addresses in a virtual network. In this post, I am going to talk about one of the recent scenarios I encountered as a part of the Fast Track for Azure team for a customer who wanted to have their internal apps as private endpoints behind an Azure Front Door Premium in order to access it securely and privately.

 

 

 

Topology Diagram:

 

1. Scenario 1 ( Common scenario where the web application is only accessible from the private endpoint connection created by Azure Front Door)

 

 

 

 

Network/Visio Diagram of scenario 1:

 

 

 

 

 

 

2. Scenario 2 ( Common scenario where the web application is accessible only from the jump box/Azure VM with another web app private endpoint connection created to test privately - Bypassing the Azure Front Door)

 

 

 

 

 

 

Network/Visio Diagram of scenario 2:

 

 

 

 

 

 

 

 

 

 

Assumptions:

 

We assume there is an existing Azure Front Door Premium profile and endpoint, with origin already added, without enabling the Private Link feature. This confirms that the Azure web application will be publicly accessible as the Private Link is not enabled yet on the web application (origin). As we enable the Private Link feature, we are going to configure the Azure web application behind the Azure Front Door to not be publicly accessible over the Internet but available privately to connect through a jump box/Azure VM in an Azure virtual network where the Private Link's private DNS zone is integrated.

 

 

 

Scenario 1:

 

Steps to enable Private Link Service for the Azure Front Door Premium Origin (Web Application):

 

For enabling the private link on the already added origin (web application), navigate to the origin groups and click on the origin group that is configured or available.

 

 

 

 

 

 

Click on the highlighted origin to modify it to enable a Private Link to the web application origin.

 

 

 

 

 

 

Click on the checkbox where it says "Enable private link Service" and enter the region where you would like to have this enabled as a private link, and for more information on supported regions where the private link feature is available for Azure Front Door Premium, please check Region Availability . Select the target sub-resource type as "sites" as this is a web app that is the origin here and give a message to request anything that you want to let the user requesting access to the private link do, like, "please enable or approve access". Click Apply to save the changes.

 

 

 

 

 

 

After applying the changes to the origin group, i.e., enabling the Private Link service, click "Update" to save origin group settings to the Azure Front Door Premium endpoint. This will save the changes to the origin group.

 

 

 

 

When a Private Link service is enabled to the origin, Azure Front Door Premium automatically creates a private endpoint connection on the web application (origin) where the private endpoint connection is pending approval. Once this is complete, we can navigate to the web application resource to see if the pending private endpoint connection shows up there, so we approve it for further use.

 

 

 

Now we can confirm that the private endpoint is enabled as we navigate to the web app resource as seen in the below screenshot.

 

 

 

 

Clicking on the private endpoint, the pending private endpoint connection created by the Azure Front Door Premium shows up here, so we can click on the pending private endpoint connection and select "Approve" to approve it. This will take a few seconds to show up.

 

 

 

 

 

 

Now, per the pending connection, select "Approve" to approve the private endpoint connection. It will ask for confirming approval, please click "yes" to go ahead and approve the pending private endpoint connection.

 

 

 

 

It will show as "Approving" and once complete, upon clicking refresh, it will show as "Approved".

 

 

Now as we refresh after a few seconds as this operation completes, we can observe that the connection state shows as "Approved" for the private endpoint connection.

 

 

 

 

Test the web application if it is used as a private endpoint (Private Link-enabled Origin for Azure Front Door Premium )

 

 

 

Let's now try launching the web application in a browser window and we will see that the web application is not accessible publicly. We get an ERR_NAME_NOT_RESOLVED error while launching the web application or Azure App service URL in a browser window. This is expected as the web application is now configured to be a private endpoint, as public access is denied and it can be accessed only privately from a jump box through Azure Front Door Premium.

 

 

 

 

Since the web application (origin) is a private endpoint now, we can try launching it from a jump box/ Azure VM in the same region as the private link created by Azure Front Door. I have created a test VM with the name "mytestvm" to test the private endpoint, in the same region as the private link. I have created a Bastion host to securely RDP through a browser window into the Azure VM which is a Windows virtual machine.

 

 

 

 

Now we can test it by launching the web application from a browser window in the test VM, mytestvm, the jump box that we created to run the test for accessing the private endpoint (the web application).

 

 

 

As we see, we can now access the web application only privately through a Front Door endpoint using a Jumpbox/Azure VM in the same virtual network as the private endpoint's virtual network. This is expected as the private link connection from the Azure Front Door has no connectivity to the test-VNET where the jump box is present.

 

 

 

 

 

 

Now, let us try accessing the Front Door endpoint URLs, the endpoint hostname, and the custom domain URL from the jump box and see if we can access them privately.

 

a) Testing custom domain URL on the Azure Front Door from the jumpbox/Azure VM in test-VNET:

 

 

 

 

b) Testing endpoint hostname (azurefd.net) on the Azure Front Door from the jumpbox/Azure VM in test-VNET:

 

 

 

 

 

 

Also, the nslookup tests from the Jumpbox VM in the command prompt show that the endpoint hostname and custom domain are pointing to Azure DNS (Azure Platform DNS). We can see the nslookup tests show that it is also pointing to Azure DNS IP, 168.63.129.16 (Azure Platform DNS).

 

 

 

1. Nslookup test for the web application from the Jumpbox/Azure VM:

 

 

 

 

2. Nslookup test for the Front Door URLs from the Jumpbox/Azure VM:

 

 

 

a) Custom domain URL:

 

 

 

 

 

 

b) Endpoint hostname (azurefd.net URL)

 

 

 

 

 

 

 

 

This test clearly illustrates that the Azure platform DNS or Azure DNS is used for DNS resolution of the web application (private endpoint) as it uses internal Azure Platform DNS or Azure DNS for private DNS resolution, substantiating that the web application (origin) for the Azure Front Door Premium is now a private endpoint that is not publicly accessible but privately accessible only from a jump box/ Azure VM in the same Azure virtual network as the private endpoint.

 

 

 

Scenario 2: Pushing code to the internal web application (private endpoint) from a jump box / Azure VM bypassing Azure Front Door enabled private link connection and using a newly created private endpoint connection to the web app

 

For us to connect to the private endpoint (the web application) bypassing the Azure Front Door, to push code changes to the web application from a jump box instead of the private endpoint created by Azure Front Door (global), we need a separate private endpoint to be created to achieve this scenario or test. Now let us create a separate private endpoint (MyPEtoTest) for this scenario in the private endpoint subnet in the same VNET (test-VNET) as the jump box or Azure VM.

 

 

 

Test from the VM/jump box to the private endpoint (The internal web application using the private endpoint connection that we manually created to test connectivity and accessing the scm.azurewebsites.net to push code changes):

 

 

 

 

 

 

When I run the nslookup test from the Azure VM/ jump box bastioned into it, to test if the internal web application is resolving to the manually created private endpoint connection that we created to test connectivity to the internal web application behind the Azure Front Door as a private link origin.

 

 

 

 

 

 

You can see and validate the private endpoint's private IP with the below picture that shows the private IP seen in the nslookup is correct and matches the newly created private endpoint's private IP.

 

 

 

 

 

 

I hope you enjoyed this post, and that it was useful and helpful!

 

 

 

Happy Learning!

 

 

 

FastTrack for Azure: Move to Azure efficiently with customized guidance from Azure engineering. FastTrack for Azure – Benefits, and FAQ | Microsoft Azure

 

Continue reading...