App Service cannot connect to Azure SQL Database despite firewall and VNet rules

Question

App Service cannot connect to Azure SQL Database despite firewall and VNet rules

Adel M 0

We have an Azure App Service that is unable to connect to an Azure SQL Database. The following configuration steps have already been completed, but the issue persists:

All App Service outbound IPs are added to the SQL Server Firewall and Virtual Networks rules.

“Allow Azure services and resources to access this server” is enabled.

Virtual networks are configured and integrated with the App Service.

The connection string in the App Service is correct and follows Azure SQL guidelines.

Despite these configurations, the App Service still fails to connect to the SQL Database.

Request: Could you please help identify why the App Service cannot establish a connection and confirm if there are any additional requirements (DNS, private endpoint configuration, NSG/UDR rules, or service endpoint settings) that may be preventing connectivity?

Please also advise how we can best verify which IP/DNS path the App Service is using when attempting to connect to the SQL server.

Alex Burlachenko 18,310 Reputation points Volunteer Moderator

2025-10-01T09:31:24.17+00:00
Hey Adel,

let's verify the actual outbound path. your app service might not be using the ips you added to the firewall. when you use vnet integration, the outbound traffic can come from the vnet's ip space, not the app service's published outbound ip list.

go to your app service and open the console (kudu). from there, use nslookup to resolve your sql server's name. then, use tcpping your-sql-server.database.windows.net 1433. this will show you the actual ip and port being used for the connection attempt.

check the network security group attached to the vnet's subnet. it must have an outbound rule that allows traffic to sql service tag on port 1433. an overly restrictive nsg is a very common blocker.

if you are using private endpoints for the sql database, you must have a private dns zone configured. the app service needs to resolve the sql server's name to its private ip address, not the public one. you can test this from the kudu console. if the nslookup returns a public ip, your private dns is not set up correctly.

for vnet integrated access, you should use the sql server name, not a custom domain. also, make sure the connection string does not have encrypt=false as azure sql now requires encrypted connections.

this kind of deep network troubleshooting is a universal cloud skill. the same principles of checking nsgs, dns, and routing tables apply to aws and google cloud as well.

so, use the kudu console to run nslookup and tcpping to see the connection path. then, double check your vnet's nsg for outbound rules and verify your private dns zone if using private endpoints.

Alex

and "yes" if you would follow me at Q&A - personaly thx. P.S. If my answer help to you, please Accept my answer

https://ctrlaltdel.blog/
Adel M 0 Reputation points

2025-10-01T09:48:39.0066667+00:00

Ok, I paid for the support plan so I'm expecting to get technical support on my own case, not just general tips, Can you help ?
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Adel M 0 Reputation points

2025-10-01T09:52:45.5533333+00:00

this is what i get
Adel M 0 Reputation points

2025-10-01T09:56:00.97+00:00
Harish Peddapally 1,330 Reputation points Microsoft External Staff Moderator

2025-10-03T08:27:40.31+00:00
Hi Adel M,

Thank you for sharing the technical console screenshots and details.

May i knows Which support plan you have currently? and in the meantime, i would like to give few suggestions to help you out.

Based on your setup and verified DNS resolution, here are targeted steps:

Your App Service resolves the SQL Server to its private endpoint IP (10.0.2.4), confirming DNS setup is correct.

The consistent connection timeout on port 1433 indicates a likely NSG, UDR, or subnet routing issue blocking App Service traffic to SQL’s private endpoint.

Please:

Review all NSG rules on both subnets, add explicit Allow rules for port 1433 to 10.0.2.4.

Confirm there are no UDRs interfering with traffic.

Temporarily allow all traffic to isolate the issue, then refine NSG post-troubleshooting.

Use Azure Network Watcher’s Connection Troubleshooter for trace diagnostics.

All other SQL, DNS, and App Service settings appear correct per your screenshots.

If connection still fails after adjustments, please do let me know.

Thanks,

Harish.
Harish Peddapally 1,330 Reputation points Microsoft External Staff Moderator

2025-10-07T05:01:28.71+00:00

Hi Adel M,

Greetings for the day!

Just checking to see if you have a chance to check my previous response and helped, do let me know if you have any further questions on this.

Thanks,

Harish.

2 answers

Your answer

Alex Burlachenko 18,310 Reputation points Volunteer Moderator

2025-10-01T09:31:24.17+00:00

Hey Adel,

let's verify the actual outbound path. your app service might not be using the ips you added to the firewall. when you use vnet integration, the outbound traffic can come from the vnet's ip space, not the app service's published outbound ip list.

go to your app service and open the console (kudu). from there, use nslookup to resolve your sql server's name. then, use tcpping your-sql-server.database.windows.net 1433. this will show you the actual ip and port being used for the connection attempt.

check the network security group attached to the vnet's subnet. it must have an outbound rule that allows traffic to sql service tag on port 1433. an overly restrictive nsg is a very common blocker.

if you are using private endpoints for the sql database, you must have a private dns zone configured. the app service needs to resolve the sql server's name to its private ip address, not the public one. you can test this from the kudu console. if the nslookup returns a public ip, your private dns is not set up correctly.

for vnet integrated access, you should use the sql server name, not a custom domain. also, make sure the connection string does not have encrypt=false as azure sql now requires encrypted connections.

this kind of deep network troubleshooting is a universal cloud skill. the same principles of checking nsgs, dns, and routing tables apply to aws and google cloud as well.

so, use the kudu console to run nslookup and tcpping to see the connection path. then, double check your vnet's nsg for outbound rules and verify your private dns zone if using private endpoints.

Alex

and "yes" if you would follow me at Q&A - personaly thx. P.S. If my answer help to you, please Accept my answer

https://ctrlaltdel.blog/
Adel M 0 Reputation points

2025-10-01T09:48:39.0066667+00:00

Ok, I paid for the support plan so I'm expecting to get technical support on my own case, not just general tips, Can you help ?
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Adel M 0 Reputation points

2025-10-01T09:52:45.5533333+00:00

this is what i get
Harish Peddapally 1,330 Reputation points Microsoft External Staff Moderator

2025-10-03T08:27:40.31+00:00

Hi Adel M,

Thank you for sharing the technical console screenshots and details.

May i knows Which support plan you have currently? and in the meantime, i would like to give few suggestions to help you out.

Based on your setup and verified DNS resolution, here are targeted steps:

Your App Service resolves the SQL Server to its private endpoint IP (10.0.2.4), confirming DNS setup is correct.

The consistent connection timeout on port 1433 indicates a likely NSG, UDR, or subnet routing issue blocking App Service traffic to SQL’s private endpoint.

Please:

Review all NSG rules on both subnets, add explicit Allow rules for port 1433 to 10.0.2.4.

Confirm there are no UDRs interfering with traffic.

Temporarily allow all traffic to isolate the issue, then refine NSG post-troubleshooting.

Use Azure Network Watcher’s Connection Troubleshooter for trace diagnostics.

All other SQL, DNS, and App Service settings appear correct per your screenshots.

If connection still fails after adjustments, please do let me know.

Thanks,

Harish.
Harish Peddapally 1,330 Reputation points Microsoft External Staff Moderator

2025-10-07T05:01:28.71+00:00

Hi Adel M,

Greetings for the day!

Just checking to see if you have a chance to check my previous response and helped, do let me know if you have any further questions on this.

Thanks,

Harish.

Answer 1

Hi Adel M,

Welcome to Microsoft Q&A and thank you for posting your query here!

The issue where an Azure App Service cannot connect to an Azure SQL Database despite having the SQL Server firewall and Virtual Network rules configured often relates to additional network and DNS configurations beyond just IP whitelisting.

Here are key points and steps to verify and resolve this:

Private Endpoint and DNS Resolution If your Azure SQL Database is configured with a private endpoint, the App Service must resolve the SQL server's fully qualified domain name (FQDN) to the private IP address of that endpoint, not the public IP. This requires proper configuration of Azure Private DNS zones (privatelink.database.windows.net) and ensuring the App Service's VNet integration supports DNS resolution to that private zone. Without correct DNS setup, the App Service will attempt to connect via the public IP and may fail.

Network Security Groups (NSGs) and User-Defined Routes (UDRs) Verify that NSGs and any UDRs on your subnet(s) or on the VNet gateway allow outbound traffic from the App Service to the SQL Database on port 1433. Incorrect NSG or route rules can block this traffic even if firewall rules seem correct.

Service Endpoints and VNet Rules IP firewall rules allowing all App Service outbound IPs only work if the SQL Server network access settings include public network access. If VNet service endpoints or private endpoints are configured, IP firewall rules might be bypassed. Service endpoints require the subnet to have the SQL service endpoint enabled and added to the SQL Server’s VNet rules.

Verification of IP and DNS used by App Service Use the Kudu Console available at https://<your-app-service-name>.scm.azurewebsites.net/DebugConsole to run commands like nslookup <sql-server-name> to check if DNS resolves to expected private or public IP. Also, application logs and Azure SQL diagnostic logging can help confirm connection attempts and source IP.

Recommended next steps:

Double-check if Private Endpoint is configured for your SQL Database and ensure the App Service’s DNS can resolve to it correctly.

Review NSG rules on the subnet hosting the private endpoint and, on any subnet, used by the App Service VNet integration.

Confirm port 1433 is allowed outbound from the App Service to the database.

If using service endpoints, verify they are enabled and properly configured on the VNet subnet.

Monitor connection attempts using Azure SQL diagnostic logs for further clues.

For detailed guidance, please refer to Microsoft official documentation below:

Troubleshoot Common Connection Issues in Azure SQL Database: https://free.blessedness.top/en-us/azure/azure-sql/database/troubleshoot-common-errors-issues?view=azuresql

Tutorial on Azure SQL Database Private Endpoint Setup: https://free.blessedness.top/en-us/azure/private-link/tutorial-private-endpoint-sql-portal

Azure SQL Database Firewall and Virtual Network Configuration: https://free.blessedness.top/en-us/azure/azure-sql/database/firewall-configure?view=azuresql

This comprehensive approach should help identify why the App Service cannot establish a connection and how to adjust networking, DNS, and security setups accordingly.

Please do let me know if you have any question on this.

Thanks,

Harish.

Answer 2

Adel M 0

User's image

Share via

App Service cannot connect to Azure SQL Database despite firewall and VNet rules

2 answers

Your answer