0

I'm trying to configure app service to connecto to Azure Sql using private endpoint as described here (but from portal): https://blog.arinco.com.au/2020/08/connect-an-azure-app-service-to-azure-sql-using-azure-private-link/

But once I did it one of my Azure Functions connected to same vnet no longer can access Storage Account. We confirmed it multiple times by removing/adding private endpoint configurations.

I'm using Timer triggered function:

The listener for function 'MyFunction' was unable to start.
innermostMessage: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

enter image description here

How can this block my access to Storage account? Maybe once I use private link for one of Paas offerings I need to use it for all?

Piotr Perak
  • 10,718
  • 9
  • 49
  • 86

2 Answers2

0

I assume by default you can access the public endpoint of the function linked storage account(select Allow access from all network), then you integrate the app into a VNet and have WEBSITE_VNET_ROUTE_ALL set to 1 which will tell the App Service or your Azure function to route all traffic via the VNET. By default, an app service routes only RFC1918 traffic to the VNET. This restricts the outbound traffic from a VNet.

In this case, you could try to add the app integrated subnet into the networking of the linked storage account.

enter image description here

Nancy
  • 26,865
  • 3
  • 18
  • 34
  • I didn't have time to check it - other priorities. But I doubt this can solve my problem as I need every IP to be able to access my storage account. It's web application that needs to present images directly from storage (with SAS token) – Piotr Perak Feb 01 '21 at 09:14
  • When you said "one of my Azure Functions connected to the same vnet no longer can access Storage Account. ", is there any other azure function connected to the same VNet still connected to the same Storage account? If so, it sounds like a problem with this Azure function itself. By default, your Azure function is connected to both the Internet and VNet with "Deploy the app service or function app into the virtual network". – Nancy Feb 01 '21 at 09:38
  • Web application on AppService also could not connect to storage account – Piotr Perak Feb 01 '21 at 10:52
  • I think so because when you set the app setting WEBSITE_VNET_ROUTE_ALL to 1, all outbound traffic from your app service plan is from your VNet. In this case, you need to either create a private endpoint for your storage account or cancel the setting WEBSITE_VNET_ROUTE_ALL to 1 or tried the above solution in my reply. You can also check if it's resolved to a public IP when `nslookup storage account FQDN` from your Azure function app---console. – Nancy Feb 02 '21 at 01:58
  • 1
    It started working when we added Service Enpdoint for Storage to VNET. We created a small repro and that't what MS support suggested. – Piotr Perak Feb 16 '21 at 12:01
  • Do you only add the Service Enpdoint for Storage to VNET then it starts working? Do you also add the app integrated subnet into the networking of the linked storage account? – Nancy Feb 18 '21 at 08:01
0

Couple of things to check,

  • Can you check via Kudu console, if the environment variable WEBSITE_PRIVATE_IP is present? If this is missing, this implies the Regional VNet Integration setup on that VM has failed. See my response here

  • Is the Web App connecting to storage via Private Endpoint or Service Endpoint?

  • Using Kudu console, run the below command to see what IP the hostname is resolving to.

    nameresolver hostname dnsServerIpAddress

    Here, the dnsServerIpAddress is optional. If not provided, then it will pick up the DNS app setting or the VNet's DNS Servers.

  • does a tcpping to storage endpoint on port 443 work? try running the below command

    tcpping storageaccount.blob.core.windows.net

You would also check the same for SQL.

If it is a Private Endpoint enabled destination, then ensure that the nameresolver resolves the hostname to a IP address of the private endpoint. If it is resolving to a public IP Address, then there is an issue with the private endpoint setup of the destination resource.

To isolate further try removing private endpoints and connect via Service Endpoints.

If nothing helps, please log a ticket with Azure Support so that they can investigate this further.

Kaushal Kumar Panday
  • 2,329
  • 13
  • 22