During implementation of the concept in Part 1 I discovered that Traffic Manager probes were not accurately reporting outages of the web app’s and would still route traffic to improperly functioning web apps. This article corrects that oversight, and combined with Part 1 is a complete solution to enable the usage of Traffic Manager, Web Application Firewall, and Web App’s together.

We left off with the following structure:

This diagram adds detail of the required changes and focuses on just one web app in one region:

Traffic Manager Web App 2

This traffic manager is configured as desired to route traffic between the different regions.  In this example we configure it geographically, but any of the four options would work.  The sole purpose of this Traffic Manager is to route traffic appropriately between the North and the South region.  It contains 2 endpoints, each of which are configured as Nested endpoints. Each of these endpoints must be configured with Minimum child endpoints of 2, this is the key to making this method work.

Traffic Manager Web App 2 South

This traffic manager is configured to understand that both the WAF and the Web App are functional to pass this knowledge upstream.  This must be configured with Priority routing, which is used to make sure that traffic only follows the route through the WAF and does not bypass it.  This traffic manager also contains two endpoints, both of which are nested, and point to the “level 2” traffic managers from the diagram above.  The Firewall endpoint should be configured with a priority of 1, and the App endpoint should be configured with a priority of 2.  How does this prevent traffic from bypassing the firewall?  The firewall traffic manager has a priority of 1 so traffic is always routed to this endpoint unless there is an outage, which would result in the other traffic manager handling the traffic. The parent traffic manager is configured with minimum child endpoints of 2, so it will not route traffic to this endpoint if either is done. So the priority 2 endpoint will never receive traffic.

Traffic Manager Web App 2 Level 2 Firewall

This traffic manager’s sole responsibility is to report the status of the WAF to it’s parent.  The routing method of Performance is best to configure for this traffic manager.  It’s endpoint monitor settings should be set at protocol TCP, port 80. (This assumes that your WAF is configured to respond on 80, you will need to match this to the configuration of the WAF.)  This has one endpoint which is configured as type Azure Endpoint, Target Resource type of Public IP address, and target resource of the static ip of your WAF for this region.

Traffic Manager Web App 2 Level 2 App

This traffic manager’s responsibility is to report the status of the Web App to it’s parent.  The routing method of Performance is best to configure for this traffic manager.  It’s endpoint monitor settings should be set at protocol HTTP, port 80. (This assumes that your Web App is configured to respond on 80, you may need to configure this as HTTPS/443)  This has one endpoint which is configured as type Azure Endpoint, Target Resource type of App Service, and target resource of the Web App.

Done?

At this point you should configure the other region in a similar manner.  If you artificially create outages in either region of either your WAF’s or Web App’s you should see appropriate fail over happening. This solved our initial problem but left us with a new problem.  We now can use the *.azurewebsites.net or *.trafficmanager.net addresses to access the web app without going through the WAF.

Preventing the Bypass of your WAF

To prevent the bypass of the WAF we configure each Web App to respond with Forbidden if traffic arrives from anywhere except the WAF or a traffic manager probe.  To do this we add the following to the web.config file:

This tells the web app to only allow traffic from the IP addresses specified in this list otherwise respond with a Forbidden.  The first two addresses are the public IP’s assigned to the WAF in the north region and the WAF in the south region.  The remaining addresses are the addresses of the Traffic Manager probes.  This turns out be a bit of a gotcha because Traffic Manager does not have a fixed IP address since it operates at the DNS level.  The Traffic Manager team has published the list of IP addresses that the probes originate from.  They can be found here.

Done

You should now be able to access the webapp through the  *.azurewebsites.net or *.trafficmanager.net address and receive a 403, but traffic through the WAF respondes correctly.