Using Azure Traffic Manager probes with IP Restrictions protecting the App

Overview

This was written by my colleague Michael Lopez; edited and published by me.

We receive many inquiries about load balancer probes, such as Azure Traffic Manager probes. A common issue we witness with health probes are with applications in Azure App Services that restrict access via Static IP Restrictions. This is when we restrict access to our Azure App Service to only certain IPs as seen below:

<?xml version="1.0"?>

<configuration>

  <system.webServer>

    <security>

      <!-- Disallows unlisted. The configuration below blocks all access to the App Service -->

      <ipSecurity allowUnlisted="false" denyAction="Forbidden">

        <add allowed="false" ipAddress="0.0.0.0" subnetMask="0.0.0.0" />

      </ipSecurity>

    </security>

  </system.webServer>

</configuration>

 

The issue with this scenario when an App Service is front-ended by Azure Traffic Manager is that we would have to include the entire range of possible source IPs where probes may arrive from on the ipSecurity allowed list (we provide this list in the following article).  My article will provide a different approach for this scenario that applies for an HTTP-based probing without having to be concerned about a health probe’s source IP.

Solution

App Service Configuration

The first thing we will need is to create an endpoint (MVC controller, Generic Handler, HTTP handler, ASP.NET Forms page, static resource, etc.) that will serve as our probe URL. For this sample, I will be using a static resource in the D:\home\site\wwwroot directory named health.html.

 

Now, we can override the original configuration using the location configuration element to override the original ipSecurity settings for only this static resource.

<configuration>

  <system.webServer>

    <security>

      <!-- Disallows unlisted. The configuration below blocks all access to the App Service -->

      <ipSecurity allowUnlisted="false" denyAction="Forbidden">

        <add allowed="false" ipAddress="0.0.0.0" subnetMask="0.0.0.0" />

      </ipSecurity>

    </security>

  </system.webServer>

  <location path="health.html">

    <system.webServer>

      <security>

        <ipSecurity allowUnlisted="true" denyAction="Forbidden">

          <clear />

        </ipSecurity>

      </security>

    </system.webServer>

  </location>

</configuration>

 

The location element and path attribute specify the configuration applies only to health.html resource in the home directory as we are modifying the web.config in the wwwroot directory. The attribute allowUnlisted set to true overrides the false value set for the rest of the application. The clear element will clear any add entries that appear in the ipSecurity list for the rest of the application. With this configuration, the rest of the application remains protected by IP Restrictions and only the resource /health.html is open to health probes.  You can see this working here:

 

 

 

Azure Traffic Manager Configuration

Now that we have a probe URL, we can set this up in Azure Traffic Manager's endpoint monitoring settings as the Path value.

After setting and saving the change, we can see the endpoint is showing as Online in Azure Traffic Manager:

Ideally, the probe URL should have the ability to determine if an application is healthy by checking if the application and its dependencies are available and report a successful status (HTTP 200) if the health check pass or a non-successful status if the health checks fail. This static resource just indicates if the site will respond by serving the static html page.  We leave that coding to you as the developer of the application!

Summary

Michael Lopez and I hope you found this useful and welcome any feedback!