Our external application cannot connect to Azure SQL Database even though I’ve added the application server’s public IP to the firewall whitelist. The connection fails with ‘access denied’ errors. I’ve verified the IP address multiple times and it’s definitely correct.
Connection error:
SqlException: Cannot open server 'prod-sqlserver' requested by login.
Client with IP '203.0.113.45' is not allowed to access server.
Error Code: 40615
The IP address 203.0.113.45 is listed in the Azure SQL Database firewall rules. I can connect successfully from Azure Portal’s query editor, but external connections fail. The application uses SQL authentication with a valid username and password. What could be blocking database connectivity despite the correct IP whitelist configuration?
Found three different outbound IPs used by our load balancer’s NAT pool. Added all three to the firewall but still getting blocked. The connection string format looks correct. Could there be a rule priority issue with IP whitelist rules?
Before whitelisting additional IPs, verify your connection string is using the correct server name format: servername.database.windows.net. Also check if there are any Azure Private Link or VNet service endpoints configured that might be interfering. If you have virtual network rules configured, they take precedence over IP firewall rules.
Use whatismyip.com or similar service from the application server to verify the actual public IP. Many corporate networks use NAT pools with multiple egress IPs that rotate. You might need to whitelist an entire range. Also check if your organization uses a proxy server - the connection might be coming from the proxy IP instead of the application server IP.
Absolutely, that’s likely your issue. Load balancers typically have separate IP addresses for outbound internet traffic. Check your load balancer’s NAT configuration to find the actual outbound IP. You may also want to enable ‘Allow Azure services’ option temporarily to see if connectivity works from within Azure network, which would confirm it’s purely a firewall IP mismatch issue.