Error 10060: Configure Azure NSG for Azure DB and Azure DW Connectivity

Published 06-13-2019 09:14 AM 6,060 Views

Error 10060: Configure Azure NSG for Azure DB and Azure DW Connectivity

Customer running Virtual Machines in the cloud require additional layer of security and as a cost-effective option is to implement Network Secure Gateways to control inbound and outbound traffic to and from their Azure hosted services.  


In the light of one wanting to connect to the Azure SQL DB or Azure SQL DW using SQL Credentials, specific ports are required through the NSG. Both Azure SQL DB and Azure DW allow Secure VNET connections and to make use of this configuration Destination Service Tags are to be applied to the Firewall Rule.


If the NSG is not correctly configured Error 10060 will be returned as a connection to the database could not be established.


For a list of required ports which need to be opened in addition to this article for AAD or Hybrid AD Domain Scenarios for Windows based Authentication please refer to following article :


Problem Scenario

Customer configured their NSG to Allow port 1433 traffic to their Azure DW as per our documentation Azure DW requires this for connectivity to complete.


A successful connection test was performed by the customer via telnet to Port 1433 of the Target Server name.




When connecting to the Target DW database we receive the following exception when connecting with SQL Credentials.



When using SSMS Error 10060 is being returned and clearly states a connection attempt failed because the connected party did not respond after a period of time.





The NSG had port 80, 443 and 1433 allowed through the firewall which according to most peoples understanding is sufficient to allow access to Azure DW. 


As per the Azure Connectivity architecture when the connection is within the Azure boundary we make use of Redirection which requires port Range 11000 to 11999 to be opened as well, when the host is outside of the Azure network it would be a Proxy connection making use of Port 1433 only.


The Firewall rules on the Logical Server allow you to change the connection policy for all inbound connections to Proxy, when doing so only Port 1433 will be required. (The Default is Proxy External to Azure, Redirect Internal to Azure)



When the following NSG Firewall rule was created we were able to connect successfully to the Target DW database using SQL Credentials.


The NSG will be associated to the VNET which the Source VM has been created in I will be limiting access to the VNET only on my DW and in order to do so will make use of the Service Tag for SQL as well in my NSG Rule.


Ensure that the Destination references : Service Tag

Ensure that the Destination Service Tag selected is :  Sql


For additional security select the Source as your Source VM VNET and not Any as per the example below



In accordance with Azure DW Best practices we limit the connection to my Azure SQL Server which hosts the DW to the following VNET only thus completing the secure end to end connection




For additional information on Service Endpoints refer to following article

Senior Member

This seems to work great for SQL Auth, however, when selecting Integrated AD auth it does not. It looks to need something on port 80 from somewhere on the internet - error relating to SSL Cert revocation, so assuming its CRL related, but as this isnt something we would openly allow (free open port 80 internet access), being able to narrow this down would be useful.

You'd think that Microsoft would publish such information clearly, but apparently not!




Hi Anthony have you tried to run a Fiddler trace to confirm where your connection is being blocked and where the authentication attempt is failing. Port 80 and 443 outbound should be allowed to all services if you restrict those ports you could face challenges. It also depends on your Domain Topology with Azure, are you using Federation, is it purely Azure AD or is it a Hybrid Scenario. Depending on which AD Topology you have in place it would require access to different services whether on-premises or in Azure. 

Senior Member

Hi, no i havent, as i was wanting to troubleshoot by reviewing the NSG flow logs, but this also has issues for which I have an open support request which has gone unresponded to after a week.


As the Azure VM is an extended part of our "internal" networks, freely opening 80 and 443 to the whole internet isnt something we would do. Does Microsoft really not publish what connections are required for each scenario? 

Version history
Last update:
‎Aug 19 2020 08:40 AM
Updated by: