You may have faced some issues while securing App Services behind an Azure Application Gateway.
More often than not, these issues are not really caused due to problems with the App Service or Application Gateway itself, but with the way the configuration & functioning of these products/services are interpreted.
In this blog post, I'm calling out one such scenario where redirects configured at the App Service web.config, end up exposing *.azurewebsites.net to the client (for example, on the browser's address bar)
CONFIGURATION:
- Custom Domain (www.customdomain.com) has a C-Name to Application Gateway’s default domain (*.cloudapp.net).
- Application Gateway has App Service Configured as the Backend Pool.
- Probes & listeners are in place for the App Service Backend Pool.
- Backend App Service has rewrite rules configured. (Say, HTTP to HTTPS)
SYMPTOM:
- When a request is made to the Application Gateway’s Custom Domain name (www.customdomain.com) –> appname.azurewebsites.net is exposed on the browser.
WHY IS THIS AN ISSUE?
- One of the main intentions for customers to use Application Gateway in front of App Service is to avoid exposing the backend application’s whereabouts to the end user.
- However, the scenario addressed here defeats the purpose of the Application Gateway.
HERE’S WHAT’S ACTUALLY HAPPENING:
- Browser makes a request to http://www.customdomain.com/
- Since the DNS C-Name entry for www.customdomain.com points to the Application Gateway, the request is sent to the Application Gateway.
- Application Gateway receives this request, terminates the request – and fires a new request to the backend pool’s address.
- Now, if ‘Pick host name from backend address’ is set to ‘True’ in the App Gateway BackendHttpSettings, the new request is actually fired to http://appname.azurewebsites.net and NOT to http://www.customdomain.com .
- Backend App Service receives this request and the re-write rules are processed. Let’s say this App Service has an HTTP to HTTPS URL rewrite rule configured.
- Due to the HTTP to HTTPS redirect, App Service returns a response with status code HTTP 302/301 and a location tag with this https://appname.azurewebsites.net as its value.
- The Application Gateway receives this response, and returns the same HTTP 302/301 response back to the browser.
- The browser then fires a new request to https://appname.azurewebsites.net which is the value in the location tag.
- This is how the *.azurewebsites.net is exposed on the browser URL.
A little about ‘PickHostNameFromBackendHttpSettings’ –
- What does this setting do?
- When this flag is checked, it means that the host header should be picked from the backend http settings.
- This means that the Application Gateway will fire a request to the App Service with appname.azurewebsites.net as the hostname.
- This also means that the AppGW will not retain the Custom Domain name while making a call to the backend.
HOW DO WE FIX THIS?
Here’s a solution we can suggest our customers when the redirects at the backends cause such issues:
Solution – Ensure that any redirects respect the domain that the user has originally requested (i.e. the application gateway domain).
- Map the domain www.customdomain.com to the backend App Service as a custom domain name.
- To do this create records in your DNS registrar with the following value
| Record Type | Host Name | Value |
| TXT | awverify.www.customdomain.com | appname.azurewebsites.net |
- The above record helps in validation at the App Service level. Once this record is in place, add www.customdomain.com as a custom domain name to the App Service.
- The TXT record can be removed after App Service validation.
- Ensure that www.customdomain.com still has the C-Name to Application Gateway (*.cloudapp.net).
- Ensure that the Application Gateway sends request to the backend App Service without modifying the hostname to appname.azurewebsites.net
- To do this, uncheck the Use for App Service, and Pick Hostname from Backend Address so that the hostname in the packet is not altered.
- When this happens, the App Gateway receives a request for http://www.customdomain.com , forwards the same to the backend, backend receives request over http://www.customdomain.com, processes the redirect request, replies with a location tag to https://www.customdomain.com , AppGW forwards the same response to the browser and the browser fires another request to https://www.customdomain.com .
- This way, the domain name is honoured throughout the cycle, thus avoiding the exposure of azurewebsites.net URL to the end user.
I hope this helps! :)