Can''t connect to SQL server remotely - Super Socket error.
-
Win2K3 all patched up. Been running fine for 3 months now.
MSSQL2000 All patched up.
Dedicated SQL server
2 NICS - One LAN One WAN
Error on server: "SuperSocket info: Failed to get Exclusive port use"
Error the user sees: SQL Server does not exist or access denied
This started in the middle of the day a last week.
Webservers on the local LAN connect just fine and run without issue.
Users can't access the server remotely using QA or EM (the same users that could connect just fine the day before).
There are other SQL Server boxes on the same LAN and LAN/WAN local/remote connection still work fine.
The SQL server is running as a "local system account" (as it has been from the start).
After reboots etc, I still get the same error.
From another SQL box on the same network I have confirmed I can connect to the problem box using it's LAN address 192.168.x.x (on it's own NIC on the box). I cannot connect using it's WAN IP (different NIC)
In the SQL logs it says the server is listenig on both IP's and port 1433.
-
firewall?
-
What else is running on the server? Sounds like something is utilizing port 1433 on the WAN connection, which is where you aren't connecting. One thing you could do is grab a tool from FoundStone called Fport. It should run on Windows Server 2003. It'll be able to tell you what apps are listening on what ports.
K. Brian Kelley
@kbriankelley -
Firewall Yes. However it's a single port GB box and all the other SQL boxes behind it connect just fine. If it were the firewall, it should be a global issue.
We opened a ticket with MS on this and so far they are scratching their heads as well - go figure.
Obviously a solution for this is the end game, however it really bothers me that this happened in the middle of the day (several weeks since the last re-boot) without any events around it. So I am as interested in the cause as I am the solution.
The server is dedicated to SQL, there is a network copy of AVG from Grisoft running on it and one file maintainance utility that runs on a schedule. Basically the same setup as 3 others that were deployed at the same time (the other 3 still work fine as well as the others that are on the same network).
-
If you netstat, is SQL Server listening on 1433 or possibly another port?
I'd double check the firewall. Firewall rules aren't necessarily global. You could have something blocked on that IP.
-
netstat shows it as listening.
The firewall has some global filtering on it, nothing IP specific. This has been checked and re-checked.
-
Did you check this out? http://support.microsoft.com/?id=830215
Briefly, the cause is:
This problem occurs because the SQL Server service account is not a member of the local administrators group on the computer. Therefore, the SQL Server service account does not have the necessary access permissions to exclusively use the TCP/IP ports.
-
We have it running as a service. We did run into that article and tried using a system admin account and still had the same issue.
One thing we found that was done on the server was a replication/publication was set up for 3 of the DB's on the box. Does anyone know if either of these services could grab the port?
-
No, they work through SQL Server. One of the issues with netstat, however, is that except in WindowsXP where you have the -b option, you don't know what is listening on 1433. That's one of the reason for programs like fport. It'll tell you what is using 1433. SQL Server may be listening on 1433 for 0.0.0.0 and for you're internal LAN address, but that doesn't mean something else hasn't grabbed it for the WAN port. Also, there isn't an IPSEC policy or anything like that which has been applied recently has there? Also, no changes to the firewall or the routers? A network guy could have made a change and this would cause the same issue.
K. Brian Kelley
@kbriankelley -
Unfortunately I can't logon locally to the box and fport won't run through TS.
Last night we removed the two WAN IP's and added two others from another class and bypassed the router and firewall and went directly into the main switch, still the same issue.
-
Try temporarily having SQL Server listen on a different port and see if you can make a connection to server,port. I seem to remember this issue happening and by switching ports and then switching them back the problem resolved. Not sure why it's in my memory banks... think it went back to a class at BlackHat 2004 a co-worker of mine attended and the same problem came up.
K. Brian Kelley
@kbriankelley -
Your issue may lie with "port allocation". One of two scenarios exist with a SQL Server installation - either the listening port is set to dynamic (the default), or one has manually set the listening port to "static". I am not an expert in this area, but have encountered a similar issue to yours.
You might want to check out Microsoft article http://support.microsoft.com/kb/823938/en-us
(From the above article): If another program is already using the specified TCP/IP port, the port is not available to the instance of SQL Server and SQL Server clients may not be able to connect to the instance of SQL Server.
This problem is specific to an instance of SQL Server that is configured to use a static TCP/IP port. This problem does not occur for an instance of SQL Server that is configured to use dynamic port allocation. In dynamic port allocation, if another program is already using the specified TCP/IP port when you start the instance of SQL Server, the instance of SQL Server selects a new port.
----------------------------------------------------------
I believe it's possible the above has occurred in your configuration. Also, this additional Microsoft article has a similar "SuperSocket" error message and may be helpful: http://support.microsoft.com/kb/293107/en-us
Try this article too: http://support.microsoft.com/kb/312935/
Hope this helps - let me know if you have any questions related to the above, and I will try to assist you if possible. Good luck!
Dave G.
Dave Gradoville, MCDBA -
If all else fails, check your ISP. I know with Telus (my ISP) they have blocked most standard inbound TCP ports like 1433. Of course that blocked any inbound connections on 1433 from the outside world. They did it to help stop the amount viruses and hackers trying to hack into their network. They did this to the residential packages. But not to the business packages. It wouldn't surprise me that other ISP's might start doing the same thing. So regretably I had to move the server to listen on a different port that wasn't blocked.
David Nyquist
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply