Azure SQL Connection Refused Errors: Causes and Fixes

The error messages and what they mean

Two error messages cover almost every Azure SQL connection failure:

Cannot open server 'myserver' requested by the login.
Client with IP address '203.0.113.45' is not allowed to access the server.
To enable access, use the Windows Azure Management Portal or run
sp_set_firewall_rule on the master database to create a firewall rule
for this IP address or address range.

This is a firewall rejection. The TCP connection reached Azure’s gateway but was dropped before it touched your logical server.

Login failed for user 'appuser@myserver'.
(Microsoft SQL Server, Error: 18456)

This is an authentication failure. The network path worked — the server received the login request and rejected it.

A third common error appears when Entra ID (Azure AD) authentication is used but SQL authentication is also attempted:

Login failed for user ''. The user is not associated with a trusted SQL Server connection.

This means SQL authentication is disabled on the server and only Entra ID authentication is allowed, but the client sent a SQL username/password pair.

Cause 1: Firewall rule missing or wrong

Azure SQL logical servers block all inbound connections by default. You must explicitly allow client IPs. The Azure portal tells you the blocked IP in the error message — use that exact IP when creating the rule.

Check existing firewall rules:

az sql server firewall-rule list \
  --resource-group myResourceGroup \
  --server myserver \
  --output table

Add a rule for a specific IP:

az sql server firewall-rule create \
  --resource-group myResourceGroup \
  --server myserver \
  --name "AllowMyOfficeIP" \
  --start-ip-address 203.0.113.45 \
  --end-ip-address 203.0.113.45

Allow all Azure services (use cautiously — this allows any Azure tenant, not just yours):

az sql server firewall-rule create \
  --resource-group myResourceGroup \
  --server myserver \
  --name "AllowAzureServices" \
  --start-ip-address 0.0.0.0 \
  --end-ip-address 0.0.0.0

If the client is an Azure VM or App Service, the outbound IP shown in the error may be a NAT gateway IP, not the VM’s private IP. Check the actual outbound IP using a test endpoint before creating the rule.

Cause 2: Wrong connection string format

Azure SQL connection strings follow a specific format that differs from on-premises SQL Server. The server name must end in .database.windows.net, not a bare hostname.

Correct format for ADO.NET:

Server=tcp:myserver.database.windows.net,1433;
Initial Catalog=mydb;
Persist Security Info=False;
User ID=appuser@myserver;
Password=MyPassword123!;
MultipleActiveResultSets=False;
Encrypt=True;
TrustServerCertificate=False;
Connection Timeout=30;

Common mistakes in connection strings:

• Omitting tcp: prefix and ,1433 port — some drivers require this explicitly
• Using myserver.database.windows.net as the User ID domain instead of just the server short name (appuser@myserver, not appuser@myserver.database.windows.net)
• Setting Encrypt=False on newer SQL Server drivers — recent driver versions require encryption by default and will error if the server’s certificate is unexpected

Get the correct connection string from the portal:

az sql db show-connection-string \
  --server myserver \
  --name mydb \
  --client ado.net

This outputs the exact string with correct formatting for your chosen client library.

Cause 3: Authentication mode mismatch

Azure SQL supports two authentication modes: SQL authentication (username/password stored in SQL Server) and Entra ID authentication (formerly Azure AD). These can be enabled or disabled independently.

Check the current authentication policy:

az sql server show \
  --resource-group myResourceGroup \
  --name myserver \
  --query "administrators" \
  --output json

If azureAdOnlyAuthentication is true, SQL authentication logins will always fail with error 18456, regardless of the password. You must either use an Entra ID token or change the policy:

# Disable Entra-ID-only mode to re-enable SQL auth
az sql server ad-admin update \
  --resource-group myResourceGroup \
  --server myserver \
  --azure-ad-only-auth false

For SQL authentication errors (wrong password or nonexistent user), connect as the server admin and verify the login exists:

-- Run on master database
SELECT name, type_desc, is_disabled
FROM sys.sql_logins
WHERE name = 'appuser';

-- Run on the target database
SELECT name, type_desc
FROM sys.database_principals
WHERE name = 'appuser';

A login can exist at the server level but have no corresponding database user — or the database user exists but is mapped to a different login. Both cause error 18456.

Cause 4: Private endpoint DNS resolution failure

When Azure SQL is configured with a private endpoint, the server’s public DNS name (myserver.database.windows.net) must resolve to the private IP, not the public IP. If DNS resolution is wrong, the connection goes to the public endpoint, which may be blocked.

Test DNS resolution from inside the VNet (SSH into a VM in the same VNet):

nslookup myserver.database.windows.net
# Should resolve to 10.x.x.x (private IP)
# If it resolves to 40.x.x.x or similar, DNS is wrong

The fix requires a Private DNS Zone (privatelink.database.windows.net) linked to the VNet:

# Check if the private DNS zone exists and is linked
az network private-dns zone list \
  --resource-group myResourceGroup \
  --query "[?name=='privatelink.database.windows.net']" \
  --output table

# Check VNet links
az network private-dns link vnet list \
  --resource-group myResourceGroup \
  --zone-name privatelink.database.windows.net \
  --output table

If the zone is not linked to the VNet containing the client, DNS lookups from that VNet will fall back to public DNS and resolve to the public IP.

Cause 5: TLS/SSL version mismatch

Azure SQL requires TLS 1.2 as the minimum. Older clients or applications configured to use TLS 1.0 or 1.1 will have their connections refused at the TLS handshake stage.

The error message from a TLS failure is often less obvious:

A connection was successfully established with the server, but then an error occurred during the pre-login handshake.
(provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)

To verify TLS is the issue, test using openssl:

# Test TLS 1.2 (should succeed)
openssl s_client -connect myserver.database.windows.net:1433 -tls1_2

# Test TLS 1.1 (should fail with Azure SQL)
openssl s_client -connect myserver.database.windows.net:1433 -tls1_1

In application code, ensure the connection string does not specify TrustServerCertificate=True combined with older TLS negotiation. In .NET, set the minimum TLS version explicitly if using older framework versions.

Testing connectivity end-to-end with sqlcmd

Once firewall and network issues are ruled out, use sqlcmd to test authentication directly:

# Install on Ubuntu/Debian
curl https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add -
curl https://packages.microsoft.com/config/ubuntu/20.04/prod.list \
  | sudo tee /etc/apt/sources.list.d/mssql-release.list
sudo apt-get update && sudo ACCEPT_EULA=Y apt-get install -y mssql-tools

# Test SQL authentication
sqlcmd -S myserver.database.windows.net \
  -d mydb \
  -U "appuser@myserver" \
  -P "MyPassword123!" \
  -Q "SELECT @@VERSION, DB_NAME()"

# Test with Entra ID (requires az login first)
ACCESS_TOKEN=$(az account get-access-token \
  --resource https://database.windows.net/ \
  --query accessToken -o tsv)

sqlcmd -S myserver.database.windows.net \
  -d mydb \
  -G \
  -Q "SELECT CURRENT_USER, DB_NAME()"

A successful sqlcmd connection confirms the network path is open, the firewall allows your IP, and the credentials are valid. If sqlcmd works but your application fails, the issue is in the application’s connection string or driver configuration.