December 23, 2003 at 2:38 pm
Some of our developers created a test SQL Server instance in another physical location which they claim they can all access. They gave me the IP address so I could check it out. I can ping this address but I cannot connect to it via client tools. I downloaded sqlping from http://www.sqlsecurity.com and this tool cannot find them. They are on a different LAN than I but if can ping the IP why can't EM find it? I setup an alias for this machine in Client Network Utilities using the IP address. They claim that the server has TCP/IP and Named Pipes set up via Server Network Utilities (TCP/IP uses the default port 1433) So what else can I check (before I physically walk over there and check out the machine for myself)? The error I get is SQL Server doesn't exist or access denied (I am connecting using a SQL Server id/password which they supplied)
Francis
December 23, 2003 at 2:46 pm
Can you telnet to port 1433?
K. Brian Kelley, GSEC
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
K. Brian Kelley
@kbriankelley
December 24, 2003 at 8:03 am
Just tried. No I cannot telnet to 1433
Francis
December 24, 2003 at 8:18 am
That means: a) telnet is blocked on your LAN (it is here, but that wouldn't cause a problem connecting to SQL Server), b) a router between here and there is blocking port 1433 or c) SQL Server isn't able to bind port 1433 (or is really listening on a different port).
The developers are probably connecting via named pipes, so 1433 doesn't enter the picture for them.
If possible, ask a server administrator to run netstat -an and send you the results. Make sure the server is listening to port 1433. While you're at it, you might ask them to check the event log on the server. If SQL Server can't bind to a port, it will report an error.
If that checks out, ask your LAN team if they're blocking the port anywhere.
December 24, 2003 at 9:19 am
Server administration was blocking the port. Thanks
Francis
December 24, 2003 at 9:19 am
Server administration was blocking the port. Thanks
Francis
December 24, 2003 at 12:24 pm
quote:
a) telnet is blocked on your LAN (it is here, but that wouldn't cause a problem connecting to SQL Server)
Just a point of clarification here. Telnet usually operates on 23/tcp. But Telnet is also a terminal program. So using the terminal program telnet to 1433/tcp won't be affected if a network engineer blocks 23/tcp.
K. Brian Kelley, GSEC
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
K. Brian Kelley
@kbriankelley
December 26, 2003 at 2:08 pm
quote:
But Telnet is also a terminal program. So using the terminal program telnet to 1433/tcp won't be affected if a network engineer blocks 23/tcp.
I'm not a WAN engineer, so I can't tell you how it works. I can tell you that I can't telnet to 1433, but SQL can connect via TCP/IP to 1433. Don't know exactly what they blocked, but that's how it's working.
December 26, 2003 at 2:58 pm
When you say you can't telnet, what are you getting?
Just a blank screen (nothing seems to come back) or connection refused/could not be established?
K. Brian Kelley, GSEC
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
K. Brian Kelley
@kbriankelley
December 28, 2003 at 10:46 am
quote:
When you say you can't telnet, what are you getting?Just a blank screen (nothing seems to come back) or connection refused/could not be established?
connection refused/cound not be established
December 28, 2003 at 10:49 am
They may be doing content filtering, then.
K. Brian Kelley, GSEC
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
K. Brian Kelley
@kbriankelley
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply