Accessing Azure Functions on ILB ASEs in the Azure Portal

There are two versions of ILB ASEs, one where a custom domain must be provided with a certificate and the newer version that is created with the .appserviceenvrionment.net domain (default configuration after May 2019 unless you specify an older version of the API). If you have an ASE that has the .appserviceenvironment.net domain you will only need to make sure steps 1, 2, 3 are configured otherwise check the following configurations to make sure the functionality works as expected.

A common error when the connectivity is setup incorrectly is the “Azure Function Runtime is unreachable” message. The steps below cover the common misconfigurations

1. Make sure the user has reader access on the ASE – unfortunately this is currently required. With reader role on the ASE the user cannot make any changes to the ASE itself. This requirement may change in the future (blog written July 2019).
   https://github.com/Azure/Azure-Functions/issues/666
   
   
2. The user viewing the function app in the portal needs to be connected to the same VNET that the ILB ASE exists in whether that’s with a jumpbox as described here or through some sort of VPN (P2S or S2S) or Express route or Jumpbox (VM on the subnet).
   https://blogs.msdn.microsoft.com/mihansen/2018/03/15/private-function-apps-in-azure-government-using-app-service-environment-ase/
   
3. DNS needs to be configured: whether from the DNS servers configured on the actual VNET or using the hostfile change (Navigate to C:\windows\system32\drivers\etc\hosts). The document below covers the newer version of ILB ASEs with the appserverviceevenvironment.net domain.
   
   If you are using the ILB domain type with your own custom domain you’ll need the following entries using contoso.com as the example of your ILB ASE domain:
   
   Functionappname.contso.com
   functionappname.scm.com
   or
   *.contoso.com
   *.scm.contoso.com
   
   
   https://docs.microsoft.com/en-us/azure/app-service/environment/create-ilb-ase#dns-configuration
   
   Here’s the typical error you will see if DNS is not correctly configured for both URLs mentioned above.
   
   
4. Certs – If the certificate is signed by a public trusted CA you can skip this step. Otherwise you need to make sure the certificate is trusted by your local machine. (This is not needed if the domain of your ASE has appserviceenvironment.net).
   
5. Navigate to the root of the site ie myfunctionappname.contoso.com and make sure you get the Function App Splash screen. If you get an error saying the certificate is not trusted go ahead and ignore the warning which will trust the certificate. This works best with Chrome, IE and Edge have more strict policies.
   
   
   
   
6. Navigate to Kudu ie functionappname.scm.contoso.com and skipping the certificate message as mentioned in number three (Using the Advanced option if you are using Chrome).
   
7. When you get the credential prompt log in using the publishing profile downloadable from the Azure Portal -> Function App
   
   Example:
   Username = $functionappname
   Password = longstringvalue
   
   
   
   

At the point you “should” be able to see the functionality in the portal working as expected. If you don’t I’d recommend creating a support case to investigate what additional steps are needed. In most scenarios this should get you up and running. If you are unable to deploy using something like Azure Dev Ops check out the blog below which shows how to set up the private agent to deploy to the function app.