Using Azure Application Gateway WAF’s to secure Azure Web Apps with Traffic Manager for Geo-redundancy Part 1

Why?

What lead me down this path is my desire to use PAAS whenever possible and avoid IAAS unless its absolutely necessary. Often the number one security requirement for a deployment is to put your services behind a WAF (Web Application Firewall) to offer a first line of defense against many different types of attacks.

 

Scenario

The scenario for this article is that I have two Azure Web App’s and I want to place them behind a WAF and only allow access through the WAF, all other traffic should result in a 403 error. In addition I would like to provide georedundancy for these web app’s by standing them up in North and South Central and placing them behind a traffic manager.

 

Notes

My focus is not to cover every step of the process to create these, but to cover the aspects that are poorly documented or completely undocumented for this use case.  I will show how to expose both HTTP and HTTPs, although I would never recommend that, instead expose only HTTPs, and if you must expose HTTP make it redirect to HTTPS.

 

Configuring the Application Gateway

I’m going to gloss over a lot of detail for the Application Gateway, since most of it is well documented.  You will need to create an Application Gateway in each region and configure it as a WAF, with a Public IP address named WafPublicAddressNorth-ip.  You will not need a private IP address.

 

Backend Pools

You will need to create a backend pool for each of your services with a target pointing to the regions web app.  For example in North-Waf, create a backend pool called webapp1 and add the target of webapp1-north.azurewebsites.net. You will end up with two backend pools for each Waf. (Total of 4)

 

Health Probes

Edit (5/22): This turns out to be a good start but more work is required to get proves that work and result in automatic failover during outages, Check out Part 2 for more info.

You will need to create health probes for each of your service and for each protocol.  This means you will end up with 4 health probes for each Waf. (Total of 8) For example in North-Waf create these health probes for handling http and https for webapp1:

webapp1-http-probe

Host = webapp1-north.azurewebsites.net

Protocol = HTTP

Path = /status (this is service specific but should lead to some page that gives a 200 when all is well)

Everything Else = Defaults

webapp1-https-probe

Host = webapp1-north.azurewebsites.net

Protocol = HTTPS

Path = /status (this is service specific but should lead to some page that gives a 200 when all is well)

Everything Else = Defaults

 

HTTP Settings

You will need an HTTP setting for each service and each protocol. This means again you will end up with 4 http settings for each Waf. (Total of 8) For example in North-Waf create these HTTP Settings for handling http and https for webapp1:

http-webapp1

Protocol = HTTP

Custom Probe = webapp1-http-probe

Everything Else = Defaults

https-webapp1

Protocol = HTTPS

Custom Probe = webapp1-https-probe

Backend Authentication Certificate = Upload your CER file that matches the PFX file that goes with your SSL cert

Everything Else = Defaults

 

 

Listeners

You will need a listener for each service and each protocol.  This means again you will end up with 4 listeners for each Waf. (Total of 8) For example in North-Waf create these Listeners for handling http and https for webapp1:

 

webapp1-listener-http

Protocol = HTTP

Host name = webapp1.mydomain.com

Frontend Port = 80

Everything Else = Defaults

 

webapp1-listener-https

Protocol = HTTPS

Host name = webapp1.mydomain.com

Frontend Port = 443

Certificate Name = Upload your PFX file that goes with your SSL cert

Everything Else = Defaults

 

 

Rules

You will need a rule for each service and each protocol.  This means again you will end up with 4 rules for each Waf. (Total of 8) For example in North-Waf create these rulesfor handling http and https for webapp1:

 

webapp1-rule-http

Listener = webapp1-listener-http

Backend Pool = webapp1

HTTP Setting = http-webapp1

Type = Basic

 

webapp1-rule-https

Listener = webapp1-listener-https

Backend Pool = webapp1

HTTP Setting = https-webapp1

Type = Basic

 

This should complete the configuration of your Application Gateway

 

 

Configuring the Traffic Managers

Traffic managers are global so you only are required to create one for each service which points to the WAF in each region. For example for Web App1 create a traffic manager:

webapp1.trafficmanager.net

Routing Method Geographic

Create Endpoint: Webapp1North, Target Resource type: Public IP Address, Target Resource: WafPublicAddressNorth-ip Geo-mapping: whatever setting you want

Create Endpoint: Webapp1South, Target Resource type: Public IP Address, Target Resource: WafPublicAddressSouth-ip Geo-mapping: whatever setting you want

 

 

Configuring the DNS

DNS configuration is required to use of an undocumented (as far as I can tell) feature of Web Apps Custom Domain configuration.  You will need to create two records for each service one TXT and one CNAME record.  They are:

 

webapp1.mydomain.com  CNAME  webapp1.trafficmanager.net

awverify.webapp1.mydomain.com  TXT  webapp1-north.azurewebsites.net

This is the secret sauce that makes this all possible!

 

 

Configuring the Web Apps

The configuration of the web app is fairly simple, after your DNS addresses propogate successfully, go to each webapp and configure the custom domain and SSL cert for each.  For example for webapp1:

  1. Add the custom Domain of webapp1.mydomain.com
  2. Upload your PFX certificate for this domain
  3. Add a binding of type SNI SSL from that certificate to webapp1.mydomain.com

 

Next go to the networking settings, click IP Restrictions, and add rule.  Add the public IP Address of the Application Gateway which can be found on the overview page.

 

 

Success

At this point your should be able to successfully access your web app through both traffic manager and Application Gateway, and not be able to access it any other way!

 

 

 

 

15 thoughts on “Using Azure Application Gateway WAF’s to secure Azure Web Apps with Traffic Manager for Geo-redundancy Part 1

  • Pingback: Azure Weekly: Mar 12, 2018 – Build Azure is Growing! – Build Azure

  • Pingback: Resumo Semanal - 12 de março de 2018

  • Posted on May 2, 2018 at 8:47 pm

    Hi,
    We could not have one traffic manager? Means two CNAME records for two web apps:
    webapp1.mydomain.com CNAME mytrafficmanagerprofile.trafficmanager.net
    webapp2.mydomain.com CNAME mytrafficmanagerprofile.trafficmanager.net

    Traffic manager has an endpoint to App Gateway, so we could do host header routing to different web apps.

    Please let me know your thought, I have been struggling on this.

    Reply
    • Posted on May 3, 2018 at 2:36 pm

      The idea is that there is a traffic manager for each app that is being served and many different apps are going through the WAF in each region. Traffic Manager does have an endpoint to connect directly to a web app, and that is the correct way to configure Georedundancy without a WAF. In the above example I was trying to use georedundancy and a WAF together.

      Reply
  • Posted on May 2, 2018 at 11:15 pm

    Also are you sure about this line “Add the custom Domain of webapp1.mydomain.com”, because if we add this custom domain, traffic manager CNAME will get override.

    Reply
    • Posted on March 1, 2019 at 2:32 am

      Yes any ideas on this anyone ? Your app would have a DNS name your users use e.g. web1api.mydomain.com , you want this to go to TM. then TM passes to WAF and WAF needs to pass to web app in back end pool. web app expects custom domain web1api.mydomain.com. when setting this up at web app level it asks you to create a CNAME for this customer domain and point it to the Azure provided DNS Name. However if you do this you can not use the TM as this will get over ridden. So it looks like the awverify. TXT record might be the one that does the trick. Will test

      Reply
  • Posted on May 3, 2018 at 2:39 pm

    The custom domain name refers points to the address of each traffic manager, but the web app must be configured with the custom domain, so that Azure knows which web app to show when it gets to the web server.

    Reply
  • Posted on May 4, 2018 at 7:33 am

    Agree, but how did you configure the custom domain for web app? In my case whenever I tried to add the custom domain webapp1.mydomain.com to webapp1, it overrides the cname of traffic manager with webapp url. So I ended up like first I added the web app as an endpoint of traffic manager, then traffic manager CNAME appeared update hostnames of webapp. Then I added the custom domain of traffic manager. Later I removed the endpoint from traffic manager. I am sure that’s not the right way to do. How did you achieve that?

    Reply
    • Posted on May 22, 2018 at 12:10 pm

      I never had a the need for the traffic manager cname to appear in the web app, because there is a cname from webapp1.mydomain.com to the traffic manager name. When the traffic makes it to the web app this appears from webapp1.mydomain.com and never from the traffic manager name.

      That being said this aspect of this technique causes some issues with uptime monitoring, a new article that solves those problems is coming today which likely will answer your question as well.

      Reply
  • Posted on May 17, 2018 at 9:50 pm

    How did you configure the VNET on the Application Gateway to allow traffic to leave from the gateway to the Web App? I followed your instructions and eventually realised the VNET wouldn’t allow access to the web apps.

    Reply
  • Posted on September 12, 2018 at 6:20 am

    Hi,
    When would like to add a rule, I’ve the following error message:
    There are no http settings with pick host name from backend address set. Create a new http setting with pick host name from backend address set and then try again.
    Any idea?
    Thanks.
    FLorent

    Reply
    • Posted on September 28, 2018 at 10:08 am

      It sounds like you need to create a new http settings that targets the correct backend address set. Once that is created you should be able to create that rule using that http setting.

      Reply
  • Posted on February 8, 2019 at 5:01 pm

    The problem with the above is that if you have a redirect that needs to pass the vanity site name and not the backend site you you cannot target the backend site there you must target the vanity site (per MS Azure support). However, if you do that, you will not be able to define a rule because the rule requires that you have a back end setting on the HTTP setting… which begs the question why is that an option in the first place and do you actually set that as some applications (like ours) require it.

    I’ve got a callback scheduled with MS to walk me through this and will update if it actually gets resolved.

    Reply

Leave a Reply to Florent APPOINTAIRE (@florent_app)Cancel reply