AzureFeeds

A few days ago, we handled an interesting support case where a customer encountered the following connection error when using sqlcmd to connect to their Azure SQL Database “Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : Login timeout expired.
Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : TCP Provider: Error code 0x102.
Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : A network-related or instance-specific error has occurred while establishing a connection to servername.database.windows.net (Redirected: servername.database.windows.netxxxx8165ccxxx,6188). Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online.”

At first glance, what immediately caught our attention was the port number mentioned in the error 6188. This is not the typical 1433 port that SQL Server usually listens on. Additionally, the message referenced a “Redirected” connection, which gave us the first strong clue.

We asked the customer to run the following commands for diagnostics steps:

• ping servername.database.windows.net to identify the IP address resolved for the Azure SQL Database Server, returning a private IP: 10.1.0.200.


• nslookup servername.database.windows.net to confirm whether the resolution was happening through a custom DNS or public DNS.


• ifconfig -a to determine the local IP address of the client, which was 10.1.0.10.

With all this information in hand, we asked the customer to open a terminal on their Linux machine and execute sudo tcpdump -i eth0 host 10.1.0.200 meanwhile they are attempting to connect using another terminal with sqlcmd and we observed that the sqlcmd was:

• First making a request to the port 1433 that is expected


• And then immediately attempting a second connection to port 6188 on the same private IP. It was during this second connection attempt that the timeout occurred.

After it, based on the port and the message we asked to our customer what type of connection has this server and they reported Redirect. We explained in Azure SQL, when Redirect mode is enabled, the client:

1. Connects to the gateway on port 1433


2. Receives a redirection response with a new target IP and dynamic port (e.g., 6188)


3. Attempts a new connection to the private endpoint using this port

We reviewed the connection configuration and confirmed that Redirect mode was enabled. After speaking with the customer’s networking and security team, we discovered that their firewall rules were blocking outbound connections to dynamic ports like 6188. 

We proposed two alternative solutions: 

Option 1: Adjust Firewall Rules

Allow outbound traffic from the client’s IP (10.1.0.10) to the Private Endpoint IP (10.1.0.200) for the required range of ports used by Azure SQL in Redirect mode.

This keeps the benefits of Redirect mode:

• 
  
  
  
  • Lower latency
  
  
  • Direct database access via Private Link
  
  
  • Reduced dependence on Azure Gateway
  
  
  
  

Option 2: Switch to Proxy Mode

Change the Azure SQL Server’s connection policy to Proxy, which forces all traffic through port 1433 only.

This is simpler for environments where security rules restrict dynamic port ranges, but it may introduce slightly higher latency.

In this case, the customer opted to update the VNet’s NSG and outbound firewall rules to allow the necessary range of ports for the Private Endpoint. This allowed them to retain the benefits of Redirect mode while maintaining secure, high-performance connectivity to their Azure SQL Database.