Azure Web App VNet integration to Storage account with Private Link
Asked Answered
H

2

6

I have an API on an Azure App Service (S1) on which I configured VNet Integration (subnet 10.240.0.32/27). I also have a storage account on which I configured a Private Link (subnet 10.240.0.0/27 and got IP 10.240.0.4). It however does not work I get the following error:

StorageException: This request is not authorized to perform this operation.

Does anyone know if I need to configure anything else for this to work?

This doc states that I don't have to change any connectionstring. The connections worked before a configured the private link.

Update

I have tried with an Azure SQL Database as well. Deployed a Private Link to SQL in the same subnet as the one for storage. Not much luck here either. Getting the following error:

SqlException: Reason: An instance-specific error occurred while establishing a connection to SQL Server. The public data endpoint on this server is not accessible. To connect to this server, use the Private Endpoint from inside your virtual network.

When I add the WEBSITE_VNET_ROUTE_ALL (to make all outgoing traffic go through the vnet instead of just private IPs) to the web app and set that to 1 I get the following error:

SqlException: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 0 - A non-recoverable error occurred during a database lookup.)

Then I created a VM in the same subnet as the private links. From that VM I am able to run this command which nicely returns with the correct IP:

.\psping.exe azurenetworking.database.windows.net:1433

enter image description here


UPDATE April 2nd 2020

Had a call with Microsoft today. Turns out App Services are currently incapable of using a private DNS zone. So, you need to set up your own DNS server for now. It will be fixed but they were unable to give me an ETA. So for now it's either a custom DNS server or using Service Endpoints. I'll update this question when this changes


UPDATE June 2

Details on this have been added to the documentation: https://learn.microsoft.com/en-us/azure/app-service/web-sites-integrate-with-vnet#azure-dns-private-zones

Comes down to: To work with Azure DNS Private Zones you need to add the following app settings: WEBSITE_DNS_SERVER with value 168.63.129.16 WEBSITE_VNET_ROUTE_ALL with value 1

I wrote a blog about it for anyone interested in a full example: https://erwinstaal.nl/posts/securing-your-azure-db-connection-using-azure-private-link/

Hames answered 30/3, 2020 at 17:55 Comment(0)
V
4

The error could happen when you access your blob storage via a public endpoint but enable VNet firewall settings of storage account.

In this case of App VNet integration to Storage account connection, you can use service endpoint instead of private endpoint. To use service endpoints with your app, use regional VNet Integration to connect to a selected virtual network. Then configure service endpoints Microsoft.Storage on the subnet you used for the integration.

If you still want to use private endpoint, I am afraid that you need to use your own DNS server for name resolution from an Azure App Service (Web App, Function, or Bot) using virtual network integration to role instances or VMs in the same virtual network. See Name resolution for resources in Azure virtual networks.

With private link, the blob storage DNS name is resolved to the public IP address not a private endpoint IP address from the app service console. It looks like you are accessing blob storage outside the VNet through the public endpoint when you access from your app service. Meanwhile, it can be resolved to a private endpoint IP from the VM in the same subnet as the private endpoint. See DNS changes for private endpoints.

enter image description here

Vespid answered 2/4, 2020 at 11:9 Comment(4)
Had a call with Microsoft today. Turns out Web Services are currently incapable of using a private DNS zone. So, you're right, you need to setup your own DNS server for now. It will be fixed but they we're unable to give me an ETA. So for now its either a custom DNS server or using Service Endpoints. I'll update this question when this changes.Hames
Any example of specifically connecting Azure App Service -> Azure Storage when both are behind the same vnet (in the same region)? I've connected them both as far as I can tell everything is good, but when I try to access the storage account from the app I always get > Azure.RequestFailedException: This request is not authorized to perform this operation. RequestId:[snip] Time:2020-06-15T17:16:26.8021259Z Status: 403 (This request is not authorized to perform this operation.) ErrorCode: AuthorizationFailureNoland
@Noland see this OP's question and comment, just try to re-recreate your app integrated vNet?Vespid
I agree with @eoleary. The OP's question was for ASP -> Regional VNet Integration -> Storage Account with private link. This still does not work without a Service endpoint.Cosmopolitan
G
3

I had this problem using an app service to talk to a private sql end point, this comment made the system start working for me:

Today, I set up the following four points and tried them

  1. Create a Private DNS Zone and connect it to VNET(privatelink.blob.core.windows.net)
  2. Set the VNET DNS to 168.63.129.16
  3. Configure WebApps to Regional VNET Integration
  4. Set WEBSITE_VNET_ROUTE_ALL of WebApps to 1

I got PrivateIP from KUDU(nameresolver xxxx.blob.core.windows.net) I was also able to access it from the PrivateIP side using curl in KUDU.

It seems to be important to set both 2 and 4

From https://feedback.azure.com/forums/169385-web-apps/suggestions/38383642-web-app-and-private-dns-zone-support

Then I used nameresolver in the kudu command line environments to see which IP addresses were being resolved to. One of my environments still isn't working, but I think it's been changed so many times it's gotten into some weird state. Setting the VNET DNS was the final piece of the puzzle though

Hope it helps

Georgettegeorgi answered 27/4, 2020 at 20:9 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.