Unable to connect to private linked SQL server from azure web apps

ParthibanSekarUK-3136 0 Reputation points

I have a group of linux web apps with VNet Integration enabled on a subnet called web-tier and an azure server with private link configured on another subnet called data-tier.

I have also added nsg rules to the data-tier subnet nsg to allow inbound traffic from web-tier to data-tier on ports TCP 1433, UDP 1434, and TCP 11000-11999 on data-tier NSG (destination) and allow outbound from web-tier to data tier on web-tier NSG (source).

The SQL Server has "Redirect" connection policy with public network access disabled. I have restarted the web apps after creating the private endpoint but the web apps are still unable to connect to SQL Server.

Can anyone please advise what I may be missing here?

Azure Private Link
Azure Private Link
An Azure service that provides private connectivity from a virtual network to Azure platform as a service, customer-owned, or Microsoft partner services.
480 questions
SQL Server
SQL Server
A family of Microsoft relational database management and analysis systems for e-commerce, line-of-business, and data warehousing solutions.
13,063 questions
Azure App Service
Azure App Service
Azure App Service is a service used to create and deploy scalable, mission-critical web apps.
7,148 questions
0 comments No comments
{count} votes

2 answers

Sort by: Most helpful
  1. Luis Arias 5,366 Reputation points

    Hi Parth,

    It seems like you’ve done on your Azure environment. I suggest to do this checklist:

    • VNet Integration: Ensure that VNet Integration is properly configured for your web apps. This is necessary for your app service to reach your Azure SQL DB instance.
    • Private Endpoint: Verify that the private endpoint for your SQL Server is correctly set up and associated with the correct subnet.
    • Connection String: Check the connection string in your web app’s configuration. It should be using the private endpoint’s DNS name.
    • DNS Resolution: Ensure that the DNS settings of your VNet are configured correctly. The web app should be able to resolve the private endpoint’s DNS name to its private IP address.
    • Firewall Rules: Double-check the firewall rules on your SQL Server. Even with Private Link, the SQL Server’s firewall rules can prevent connections.
    • Application Settings: Make sure your application is correctly configured to connect to the SQL Server using the private link.

    Using advanced tools(kudo) on the app service you can start testing by curl command to the DB port and verify the proper name resolution.

    User's image

    I hope this help you. If the information helped address your question, please Accept the answer.


  2. ChaitanyaNaykodi-MSFT 23,991 Reputation points Microsoft Employee


    Thank you for reaching out.

    I understand you have configured a group of linux web apps with VNet Integration enabled on a subnet called web-tier and an azure SQL server with private link configured on another subnet called data-tier.

    Based on a similar sample documented here

    Please check on the following :

    • Note that for traffic to pass from the web app to the private endpoints, the following web app environment variables must be set in the app.json nested template.
        "siteConfig": { "appSettings": [ { "name": "WEBSITE_VNET_ROUTE_ALL", "value": 1 }, { "name": "WEBSITE_DNS_SERVER", "value": "" } ] }
      The IP Enables communication with the DNS virtual server to provide filtered name resolution to the resources.
    • Follow the validation process here and use nameresolver <Azure SQL DB name>.<Azure SQL DB private DNS zone name> from the Kudu console to validate the DNS resolution.

    Regarding your question above

    Sorry, if I may ask. If my servername is FancySqlServer.database.windows.net, should I use FancySqlServer.privatelink.database.windows.net or FancySqlServer.database.windows.net to connect to the sql server?

    I think you should use FancySqlServer.privatelink.database.windows.net although I think the DNS resolution should work for both FQDN's as documented here when the DNS resolution is tried from a linked VNET it should resolve FancySqlServer.database.windows.net to the private IP using the CNAME record.

    User's image

    Hope this helps! Please let me know if you have any questions. Thank you!