Windows Firewall blocks SQL Connection
-
I am trying to connect to a SQL-2005 Remote server through several VS-2008 applications. Two are web applications and the other is a VB.Net application. In all cases, the connection fails and the error message in the local Windows Event log is #26, suggesting that possibly the SQL server does not allow remote connections. I know that the remote SQL server is configured correctly because I have gone through all of the steps (Surface Area Configuration, SQL Config, etc). More importantly, the connection through these applications is fine when I disable my local Windows Firewall. On my Firewall I have created Exceptions for both SQL Server and SQL Browser. I have opened TCP port 1433 and UDP port 1434. In all of my research, this is the extent of the solutions provided and so I am at a loss. Turning off the Firewall while debugging is a temporary solution and somewhat safe since my network is protected by a separate Firewall device, however, I would like to resolve this issue. I think there are enough developers out there having this same problem so hopefully someone has resolved it beyond the solutions I have tried. Thanks if you can help!
-
I am trying to connect to a SQL-2005 Remote server through several VS-2008 applications. Two are web applications and the other is a VB.Net application. In all cases, the connection fails and the error message in the local Windows Event log is #26, suggesting that possibly the SQL server does not allow remote connections. I know that the remote SQL server is configured correctly because I have gone through all of the steps (Surface Area Configuration, SQL Config, etc). More importantly, the connection through these applications is fine when I disable my local Windows Firewall. On my Firewall I have created Exceptions for both SQL Server and SQL Browser. I have opened TCP port 1433 and UDP port 1434. In all of my research, this is the extent of the solutions provided and so I am at a loss. Turning off the Firewall while debugging is a temporary solution and somewhat safe since my network is protected by a separate Firewall device, however, I would like to resolve this issue. I think there are enough developers out there having this same problem so hopefully someone has resolved it beyond the solutions I have tried. Thanks if you can help!
-
Few questions: - tcp/ip is enabled? (firewall also blocks named pipes) - what tcp port your sql server is listening? - do you use dynamic ports?
The need to optimize rises from a bad design.My articles[^]
TCP/IP is enabled as well as named pipes. According to the registry, Dynamic ports is enabled which may explain the problem. After messing with this and restarting SQL server (still using Dynamic Ports) I was able to connect. The last Dynamic Port used is 4316. The weird part is that I'm not opening port 4316 on my Firewall and yet the applications can now connect. It seems as though I should configure the server to listen on a static port (or ports).
-
Few questions: - tcp/ip is enabled? (firewall also blocks named pipes) - what tcp port your sql server is listening? - do you use dynamic ports?
The need to optimize rises from a bad design.My articles[^]
Okay, here's a follow-up. The reason Dynamic IP address might have been enabled on this server is that there is also an instance of SQL-2000 running and that must have been using port 1433. I used the dynamically assigned port # that I found in the registry as the new Static port number for IPALL and restarted the SQL service. I then opened this port in my local firewall. I can connect to the SQL server through the application. I'm not sure if I have completely solved my problem but I have opened up my understanding of the issue. Thanks for the reply Mike. You pushed me in the right direction!
-
Okay, here's a follow-up. The reason Dynamic IP address might have been enabled on this server is that there is also an instance of SQL-2000 running and that must have been using port 1433. I used the dynamically assigned port # that I found in the registry as the new Static port number for IPALL and restarted the SQL service. I then opened this port in my local firewall. I can connect to the SQL server through the application. I'm not sure if I have completely solved my problem but I have opened up my understanding of the issue. Thanks for the reply Mike. You pushed me in the right direction!
Hampden Tech wrote:
there is also an instance of SQL-2000 running and that must have been using port 1433
Dynamic ports is fine. If you have another SQL Server (the older one) in port 1433, you should open 1434 (or some other port) for tcp traffic for this SQL Server (I recall you opened udp). Also make sure that the newer SQL Server is listening on 1434. When changing the network protocols, prefer using SQL Server configuration manager in SQL Server 2005.
Hampden Tech wrote:
Thanks for the reply Mike
You're welcome.
The need to optimize rises from a bad design.My articles[^]