SQL Server and App Service connectivity across subscriptions

JohnTristam 20

I have two subscriptions, we will call them A and B. Subscription A has an app service that should only be accessible via private endpiont (user's will VPN into the environment via P2S). Subscription B has a SQL Server with a few DB's the app service needs connectivity to. I have created a private endpoint on the app service side, with a private dns zone, and I have done the same on the SQL server side. I also configured VNet integration on the app service side, and connected it directly to the VNet SQL server is on in subscription B.

My understanding is the private endpoint with an app service is only for inbound connections, while the vnet integration would be for outbound. Next, I went to the private dns zone in Subscription A for the app service, and linked it to the SQL Servers VNet in subscription B. In my head, this should give the SQL server connectivity to the app service inbound via private link service without the need for a VNET peer, and the VNet integration should work for outbound as the app service is directly integrated with the SQL servers VNET.

That being said, when testing, I am still unable to get connectivity from resource to resource. What am I missing? Do I need to add the app settings similar to what is mentioned here: https://techcommunity.microsoft.com/t5/apps-on-azure/access-to-web-app-behind-a-private-endpoint/m-p/2122208/highlight/true#M215

Silvia Wibowo 5,286 Reputation points Microsoft Employee

2024-04-08T05:08:25.1633333+00:00
Hi @JohnTristam , I understand that:

You have an Azure App Service in Subscription A, vnet-integrated with Vnet A

You have an Azure SQL DB in Subscription B

Your App Service needs to connect to Azure SQL DB

You need to:

Create a private endpoint for Azure SQL DB in Vnet A. Reference: create a private endpoint in different subscription.

Go to Subscription B, then approve the pending private endpoint request.

As your private endpoint is in the same Vnet as your App Service (Vnet A), you don't need any vnet peering.

Please accept an answer if correct. Original posters help the community find answers faster by identifying the correct answer. Here is how.
JohnTristam 20 Reputation points

2024-04-08T13:54:29.56+00:00

@Silvia Wibowo No, I have an Azure App Service in Subscription A, which is integrated to VNet B in Subscription B with the SQL Server. My thinking was this will provide direct outbound connectivity right into the VNet the SQL Server lives on.

For inbound access to the App Service from the SQL Server, you are saying I need to create a private endpoint to the Azure SQL DB in VNet A? But what confuses me here is that will not provide inbound access to the app service, that will also be out bound to the SQL Server which is already accomplished with the VNet integration to VNet B.

I could see the above working if VNet integration worked for both outbound and inbound connections, but "it doesn't grant inbound private access to your app from the virtual network".

I suppose I could try creating a private endpoint for the App Service in VNet B instead, the reverse of what you recommended.
Silvia Wibowo 5,286 Reputation points Microsoft Employee

2024-04-08T23:40:28.1433333+00:00

Hi @JohnTristam , please clarify how your app work. Is the flow like this:

User (VPN, peered to vNet B) -> App Service (vNet integrated with vNet B) -> SQL DB

I don't understand why you put PE (Private Endpoint) for App Service in vNet B. As mentioned before, PE is only for inbound request to that particular service, so PE for App Service is for inbound request to App Service, and PE for SQL DB is for inbound request to SQL DB.

In your diagram, what is the line between SQL Server (I assume this is Azure SQL DB PaaS) and vNet B?
JohnTristam 20 Reputation points

2024-04-09T00:00:43.29+00:00

@Silvia Wibowo yes that is the correct flow, User (VPN, peered to vNet B) -> App Service (vNet integrated with vNet B) -> SQL DB.

From what you are saying, it sounds like I do not need a private endpoint on the app service for inbound access in order for the app service to receive data from the SQL database.

id like users to be able to VPN into the environment, and access the app service front end which is why I figured the private endpoint was needed for inbound access to the app service.
Silvia Wibowo 5,286 Reputation points Microsoft Employee

2024-04-09T01:48:55.8533333+00:00

Hi @JohnTristam , you configure PE for App Service where users are able to VPN into. Azure SQL DB doesn't need to initiate connection to App Service, it simply responds to the inbound request from App Service that it receives via SQL DB PE.

Technically, you can use the same vNet (vNet B) for both PEs (App Service and SQL DB), but security wise, it will be better to separate them. Why? If both PEs are in the same vNet, users can access directly to SQL DB if they have the SQL DB connection parameters (hostname, user, password). Unless you intend to have that capability.
JohnTristam 20 Reputation points

2024-04-09T02:37:58.57+00:00

@Silvia Wibowo Ok, just so I make sure I completely understand - For connecting the App Service to SQL DB so it can pull data with no public access, only the VNet integration to virtual network with SQL DB private endpoint is necessary.

The purpose of the private endpoint on the App Service is for end user's to connect to the app service, and I can connect it to any VNet with a virtual network gateway (does not have to be the same VNet as the SQL DB PE).
Silvia Wibowo 5,286 Reputation points Microsoft Employee

2024-04-18T00:29:15.98+00:00

Hi @JohnTristam , your understanding is correct. Let me summarize it as a new answer. I'd appreciate if you can accept the answer. Original posters help the community find answers faster by identifying the correct answer. Here is how.

Accepted answer

Silvia Wibowo 5,286 Reputation points Microsoft Employee

2024-04-18T00:34:35.9466667+00:00

Users --(1)--> App Service --(2)--> SQL DB (no public access)

For (2): App Service need vNet integration with vNet B. SQL DB needs a Private Endpoint in the same vNet (vNet B).

For (1): If you require that App Service is not publicly accessible, create a Private Endpoint in vNet A. Users then VPN into vNet A to access App Service via Private Endpoint.
Please sign in to rate this answer.

0 comments No comments
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

1 additional answer

KapilAnanth-MSFT 48,736 Reputation points Microsoft Employee

2024-04-08T17:52:25.86+00:00
@JohnTristam ,

Welcome to the Microsoft Q&A Platform. Thank you for reaching out & I hope you are doing well.

From your verbatim,

You have an AppService (from SubscriptionA) integrated into a VNETB in SubscriptionB

You have a SQL Service (from SubscriptionB) with a PrivateEndPoint in VNETB in SubscriptionB

You have a PE for AppService (from SubscriptionA) in the VNETA (SubscriptionA)

"My understanding is the private endpoint with an app service is only for inbound connections, while the vnet integration would be for outbound"

Yes, this is correct.

"I went to the private dns zone in Subscription A for the app service, and linked it to the SQL Servers VNet in subscription B. In my head, this should give the SQL server connectivity to the app service inbound via private link service without the need for a VNET peer"

Incorrect

Private DNS Zone is only for name resolutions, this does not provide connectivity.

From your verbatim, Point 3,

A PE only provides inbound connectivity for resources that are connected to the VNET in which the PE resides.

In this case, VNETA is where the PE resides.

And VNETA is not connected to VNETB, Hence no resource in VNETB can access the AppService PE in VNETA

If my observation of your existing architecture is incorrect - Please share an architecture diagram as to avoid confusions

Now,

Your requirement is to provide bidirectional connectivity between AppService and the SQL Servers. Correct me if I am wrong.

You having AppService Integration in VNETB and a PE for SQL Service in VNETB provides App Service access to SQL via PE. (this is unidirectional)

Now, unless and until

you integrate the SQL Service to the VNETB

and create a PE for AppService in VNETB
The SQL Service cannot access the App Service.

And AFAIK , only Azure SQL Managed Instance supports VNET integration. See : Supported Azure services into virtual networks.

However, I do not understand why you would need inbound access from Azure SQL Service to App Service in the first place.

AFAIK, Azure SQL Service cannot make outbound connections.

Can you please elaborate how exactly are you testing the "connectivity from Azure SQL Service" to the App Service?

Cheers,

Kapil
Please sign in to rate this answer.
JohnTristam 20 Reputation points

2024-04-08T18:00:33.9833333+00:00

@KapilAnanth-MSFT I seem to have achieved bidirectional connectivity using the configuration below:

App Service in Subscription A on VNet A integrated with VNet B where SQL Server resides (Outbound Access)

SQL Server has private endpoint configured on VNet B.

Configured Private Endpoint for app service on VNet B.

This allows the App Service to receive data from SQL Server.

Do you see any issues with this configuration?

KapilAnanth-MSFT 48,736 Reputation points Microsoft Employee

2024-04-08T18:14:23.66+00:00

@JohnTristam ,

I am confused as what you mean by "VNet B where SQL Server resides (Outbound Access)"

Correct me if I am wrong, but as per my understanding, SQL Server does not support VNET integration.

Are you using Azure SQL Database (PaaS) or SQL Server on Azure VMs (IaaS)

Cheers,

Kapil

JohnTristam 20 Reputation points

2024-04-08T19:28:35.73+00:00

@KapilAnanth-MSFT Appreciate your responses. The SQL Server is not integrated with a VNet. We are using the PaaS solution, and it has a private endpoint on VNetB. I have also connected a private endpoint to the App Service and placed it on VNet B, which seems to be facilitating connectivity. I just want to make sure this is a supported configuration.

Attached is a diagram.

KapilAnanth-MSFT 48,736 Reputation points Microsoft Employee

2024-04-10T11:17:57.5933333+00:00

@JohnTristam ,

Wrt your diagram,

You have a PE for SQL Server (PaaS Service) in VNET B

You have the App Service integrated into VNET B.

Now,

We already established only PE can provide inbound connectivity (via Private Network) and VNET integration can provide outbound connectivity (via Private Network)

So, App Service -----> SQL Server happens via Private Network.

But I don't think SQL Server ----->App Service is happening over Private Network. Rather, it's using Public Internet (if at all SQL Server is making outbound calls in the first place).

If you don't need SQL Server ----->App Service via Public Internet,

Your set up is fine and is configured correctly.

So, the statement "For connecting the App Service to SQL DB so it can pull data with no public access, only the VNet integration to virtual network with SQL DB private endpoint is necessary." is correct

If you need SQL Server ----->App Service

I have limited expertise on SQL Server, so if you could confirm that SQL Server needs to make and is in fact capable of making outbound connection, do let me know

Currently, SQL Server ----->App Service has no private route and is leveraging internet (i.e., if SQL Server is capable of making outbound connections)

As mentioned by @Silvia Wibowo, "Azure SQL DB doesn't need to initiate connection to App Service, it simply responds to the inbound request from App Service that it receives via SQL DB PE." AFAIK.

Hope this adds some clarity

Cheers,

Kapil
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

SQL Server and App Service connectivity across subscriptions

1 additional answer

Your answer