If an AppService is called directly via its IP, either the certificate is invalid or the page cannot be found. If the call is made via HTTPS, the automatic generated certificate only stores the DNS name and not the IP, therefore is the error message:

~$ curl -i https://20.105.232.25/
curl: (60) SSL: no alternative certificate subject name matches target host name '20.105.232.25'

If the call without HTTPS is allowed, the service responds is 404:

~$ curl -i http://20.105.232.25/
HTTP/1.1 404 Site Not Found
Content-Length: 2667
Connection: close
Content-Type: text/html

This is because it is a shared service where multiple websites operate under the same virtual IP. The correct forwarding is based on the correct host value given in the header. If the call is made via IP and the host value is set correct in the header, the call succeeds:

~$ curl -i -H "Host: tzuehlke20221224.azurewebsites.net" http://20.105.232.25/
HTTP/1.1 200 OK
Content-Length: 4558
Content-Type: text/html
Date: Mon, 26 Dec 2022 12:29:52 GMT
Server: Kestrel
...

However, if the AppService is to be called via an NVA or other services, this service must support the rewriting of the host header or other ways can be used to achieve this.

Variant 1: ASE

“The Azure App Service Environment v2 is an Azure App Service feature that provides a fully isolated and dedicated environment for securely running App Service apps at high scale.” Because this is no longer a shared infrastructure, the call can also be made directly via IP address or without a host header value.

Variant 2: Application Gateway

The application gateway can rewrite the host header in the backend settings. If the service in the backend is an Azure service, an encrypted connection to the backend can be used with well known CA certificate. The host value for the header can be taken directly from the backend or entered manually:

This means that a call to a backend can now be made via a custom domain (stored as a listener in the AppGW) or via the IP of the AppGW.

Variant 3: API Management

Azure API Management can encapsulate multiple APIs in the backend, control and monitor access to them, and support the entire API lifecycle. The Azure App Service can be stored as an API with the GET function in the APIM. The host header is automatically rewritten. All you have to do is add the App Service as a backend to an API:

The call can then be made via the URL of API Management or a custom domain. The API Management call as IP could be done with a Self-Hosted Gateway or Isolated API Management.

Variant 4: Custom Domain for the AppService

If a host header rewrite cannot be done, an alternative host value can be included in the header directly on the first call. For example, if an NVA only supports forwarding to an IP, the NVA can be called up with an alternative URL that is also stored in the app service. For this purpose, a custom domain can be stored in the app service:

Subsequently, the target IP of the custom domain can be changed by pointing to another service (e.g. NVA or AppGW). This service can now forward to the App Service’s IP because the original host value of the header (custdom) is automatically passed:

The test via a configured Application Gateway succeeded:

 ~$ nslookup custdom.zuehlke.cloud
...
Name:   custdom.zuehlke.cloud
Address: 51.144.17.207

:~$ curl -i http://custdom.zuehlke.cloud/
HTTP/1.1 200 OK
Date: Mon, 26 Dec 2022 14:41:42 GMT
Content-Type: text/html
Content-Length: 4558
Connection: keep-alive
Server: Kestrel
...

Unsuitable Services

There are Azure services that do not support a host header rewrite. The following services are currently not support the feature:

  • Azure Load Balancer
  • NAT Gateways