How do I lock down the access to my backend to only specified instance(s) of Azure Front Door ?

Question

We have configured a basic On-Premise Web service under FrontDoor and want to whitelist only the FrontDoor traffic in the firewall.

Noticed that, Microsoft has given a list of IP range for FrontDoor to restrict and also mentioned that "Front Door's backend IP space may change later, however, we will ensure that before that happens, that we would have integrated with Azure IP Ranges and Service Tags. We recommend that you subscribe to Azure IP Ranges and Service Tags for any changes or updates" .

https://www.microsoft.com/en-us/download/confirmation.aspx?id=56519

Our Network team doesn't want to go with list of dynamic MS IP ranges and also there is no feasibility at this moment for other options like FrontDoor header checking, Web service rule filtering, NSG tag etc.,

By going through multiple forums we found that, Anycast IP address range 147.243.0.0/16 is recommended by most of them and also listed in the Microsoft IP range list. We also did a testing by allowing this range and it worked.

Now the question is, Are we good to whitelist only this bigger subnet range 147.243.0.0/16 and it's guaranteed that there won't be any issues or change in the future?
We want to be 100% before making this change permanently on the Production environment.

Any thoughts or suggestions please?

Answer 1

Hello @Chittybabu V ,

Welcome to Microsoft Q&A Platform. Thank you for reaching out & hope you are doing well.

I understand you have a basic On-Premise Web service behind Azure Front Door and you would like to whitelist only the Front Door traffic in the firewall but don't want to go with the list of dynamic MS IP ranges which may change later. You also found the Anycast IP address range 147.243.0.0/16 which is working for you but would like to be 100% sure before whitelisting this range on the Production environment.

You also mentioned that there is no feasibility at this moment for other options like Front Door header checking, Web service rule filtering, NSG tag etc.

However, to lock down your application to accept traffic only from your specific Front Door, you can use one of the following ways:

1. You can set up IP ACLs for your backend
2. Restrict the traffic on your backend to the specific value of the header 'X-Azure-FDID' sent by Front Door.

Look for the Front Door ID value under the Overview section from Front Door portal page. You can then filter on the incoming header 'X-Azure-FDID' sent by Front Door to your backend with that value to ensure only your own specific Front Door instance is allowed (because the IP ranges are shared with other Front Door instances of other customers). Apply rule filtering in your backend web server to restrict traffic based on the resulting 'X-Azure-FDID' header value (Examples are provided on how to apply the rule filtering with 'X-Azure-FDID' header value).

Refer : https://learn.microsoft.com/en-us/azure/frontdoor/front-door-faq#how-do-i-lock-down-the-access-to-my-backend-to-only-azure-front-door-

Now, coming back to your question,

Are we good to whitelist only this bigger subnet range 147.243.0.0/16 and it's guaranteed that there won't be any issues or change in the future?

I discussed this with the Azure Front Door Product Group team and below is their response:
There is no 100% guarantee that the IP range will not change in the future. You would run the risk of blocking good traffic if you decide to only whitelist 147.243.0.0/16.

NOTE : Static IP for Azure Front Door is in the roadmap but is a stretch goal (not in the near future).

You can also refer AzureFrontDoor.Backend section in Azure IP Ranges and Service Tags for Front Door's backend IP address range or you can also use the service tag AzureFrontDoor.Backend in your network security groups.
Since your Web service is deployed on-premise, you can use service tag discovery API to programmatically retrieve the current list of service tags together with IP address range details.
Refer : https://learn.microsoft.com/en-us/azure/virtual-network/service-tags-overview#service-tags-on-premises

Kindly let us know if the above helps or you need further assistance on this issue.

----------------------------------------------------------------------------------------------------------------

Please "Accept the answer" if the information helped you. This will help us and others in the community as well.