Azure function can't connect to its own storage account over vnet any more

Question

I have a function app running inside E1:1 app service (i.e. not consumption model). This app service is integrated into a vnet, with a subnet allocated to it. The storage account for this azure function (i.e. where the function app files are stored) has networking defined to only allow connections from specified IPs and virtual networks and has the vnet for this service plan included. This configuration has been in place for several months now, working perfectly fine.

Last Friday (31/03/2023), the function app started failing. It complains that it can't access files in the storage account. If I change storage account networking set up to allow access from all networks, then the function app works correctly. Yet, all networking was correct - and nothing changed in the configuration. Obviously, something changed on Azure side - but what?? And what do I do about it?

Answer 1

We also had this issue but we were able to resolve it. Posting our problem/solution here so it might help someone.

We were unable to connect to any service in the virtual network from our function app. Using the Kudu debug tool proved to be very helpful in pinpointing this issue. As described in more detail on: https://learn.microsoft.com/en-us/troubleshoot/azure/app-service/troubleshoot-vnet-integration-apps

This told us that the DNS was working, but we could not ping the address.

After contact with Microsoft support we found that the problem was in the route table. After temporarily removing the route table from the subnet everything started working again. But this would break the connection between the virtual network and the on premise network.

Later I got the following communication from Microsoft:

You will need to remove the UDR route udr-vnetlocal from the Route Table rt-spokehub then the Private Endpoint should send the traffic as expected with the route table associated to the subnet.

There is currently an issue where the Private Endpoint route is being invalidated when you have the Private Endpoint Policies enabled for the subnet and a more specific UDR route is added. There is a fix being implemented to resolve this. Leaving the 0.0.0.0/0 route in the UDR is fine as it won't invalidate the Private Endpoint routes. I provided documentation below as well. Manage network policies for private endpoints - Azure Private Link | Microsoft Learn

Fortunately in our case the route udr-vnetlocal was not required, so we could just remove it and everything was working fine again.

Answer 2

I tried to reproduce the same in my environment I got the results successfully like below:

Created azure function to connect storage account over vnet like below:

Configure Vnet integration:

When I access with storage account with specfic network it work successfully like below:

Last Friday (31/03/2023), the function app started failing. It complains that it can't access files in the storage account. If I change storage account networking set up to allow access from all> networks, then the function app works correctly. Yet, all networking> was correct - and nothing changed in the configuration. Obviously,> something changed on Azure side - but what?? And what do I do about it?

This issue may cause:

• Check whether the virtual network of your subnet is associated with any other service may cause this issue
• Check if there are any Azure service updates or incidents that may have impacted your function app's networking or storage account.
• You can view the Azure Activity Log to see if any changes were made to your app service or storage account around the time when the issue started occurring.
• Another possibility is that if storage account may moved to a different region or availability zone, which could affect its connectivity to the VNet. You can check the storage account's region and availability zone settings to rule out this possibility