On this page
Why it happens
Error 40615 is an Azure SQL Database error, not an on-premises SQL Server one. It does not mean your username or password is wrong. It means Azure looked at the public IP address your connection is coming from, checked it against the firewall rules on the logical server, found no rule that allows it, and blocked the connection. The message even prints the exact IP it saw: Client with IP address 203.0.113.24 is not allowed to access the server.
Every Azure SQL logical server sits behind a firewall that denies all traffic by default. You must explicitly allow each client IP (or IP range) through a server-level firewall rule, a database-level firewall rule, or a virtual network rule. Until a matching rule exists, valid logins are still turned away at severity 16, which is a normal, correctable configuration error rather than a server fault.
The usual triggers are connecting from a new network whose public IP has never been allowed, a home or office IP that changed since you last added it, or an Azure-hosted app (App Service, Function, VM) whose outbound IP is not on the list. If you were on-premises you would see a login error such as 18456 or a network error such as 53 instead; 40615 is specific to the Azure firewall.
Examples
Connecting from an IP with no firewall rule
-- Connect to myserver.database.windows.net from a laptop
-- whose public IP (203.0.113.24) has no firewall rule.
SELECT @@VERSION;Msg 40615, Level 16, State 1, Line 1 Cannot open server 'myserver' requested by the login. Client with IP address '203.0.113.24' 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.
The same app works from one network but not another
-- Office network (198.51.100.10) has a rule and connects fine.
-- The same app run from home (203.0.113.24) is blocked.
SELECT DB_NAME() AS current_database;Msg 40615, Level 16, State 1, Line 1 Cannot open server 'myserver' requested by the login. Client with IP address '203.0.113.24' is not allowed to access the server.
How to fix it
Add a firewall rule for the client IP in the Azure portal
The quickest fix is to allow the exact IP from the error message. In the Azure portal open your SQL server (the logical server, not the database), go to Security > Networking > Firewall rules, click Add your client IPv4 address (or type the IP shown in the message), then Save. The connection works within a minute or two.
-- No T-SQL needed: Azure portal path is
-- SQL server > Security > Networking > Firewall rules
-- > Add your client IPv4 address > Save.
-- The IP to allow is the one printed in the 40615 message: 203.0.113.24Create the firewall rule with T-SQL on the master database
If you can already connect from an allowed machine, add the rule in code. A server-level rule is created by running sp_set_firewall_rule while connected to the master database. Use a start and end IP to allow a single address or a range.
-- Run this connected to the master database of the logical server.
EXECUTE sp_set_firewall_rule N'MyRule', '203.0.113.24', '203.0.113.24';
-- For a small range (for example a changing home IP):
EXECUTE sp_set_firewall_rule N'HomeRange', '203.0.113.0', '203.0.113.255';Allow Azure services to connect for Azure-hosted apps
If the client is an Azure App Service, Function, or VM, its outbound IP can be hard to pin down and may change. On the servers Networking blade enable Allow Azure services and resources to access this server, which lets connections from inside Azure through. For production prefer a Private Endpoint or VNet rule rather than opening all Azure traffic.
-- Portal: SQL server > Security > Networking
-- > Exceptions > tick 'Allow Azure services and resources
-- to access this server' > Save.
-- Equivalent T-SQL creates the special 0.0.0.0 rule on master:
EXECUTE sp_set_firewall_rule N'AllowAllAzureIPs', '0.0.0.0', '0.0.0.0';How to prevent it
Remember that home and office public IPs change, so a single-IP rule you added last week can stop working without warning. Allow a small stable range, or route through a service that gives you a fixed outbound IP, so a routine IP change does not break connectivity and produce 40615 again.
Script your firewall rules as part of deployment instead of clicking them in one at a time, and for production workloads use Private Endpoints or virtual network rules so traffic never traverses the public internet. Account for changing client IPs in CI, laptops, and Azure App Service outbound addresses up front rather than reacting to each block.
Common questions
Why does the same app work from one network but not another?
Error 40615 is about the public IP address you connect from, not your login. One network has a firewall rule that allows its IP and the other does not, so Azure blocks the second one even though the username, password, and connection string are identical. Add a firewall rule for the blocked IP shown in the message.
How do I allow an Azure App Service to connect to Azure SQL?
Enable "Allow Azure services and resources to access this server" on the SQL server Networking blade, which lets connections from inside Azure through, or better, add the App Service outbound IPs as firewall rules, or use a Private Endpoint or VNet rule so the app connects privately without depending on changing public IPs.
Is error 40615 the same as a login failure like 18456?
No. Error 18456 means the login or password was rejected, while 40615 is an Azure SQL firewall block that happens before authentication is even considered. With 40615 your credentials may be perfectly valid; the connection is refused only because your client IP is not on the allowed list.