Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have researched as much as I can think to do and am stuck trying to get a telnet connection working between two windows 2008 servers.

An application on Server A needs to make a connection to Server B via port 1433 (ms sql). I have verified that Server B has it's firewall open and is accepting connections on port 1433 as I can telnet to Server B on port 1433 from 3 different servers.

The problem is I still can not telnet from Server A. I assumed this is because of a software or hardware firewall.

To troubleshoot I have ensured that the control panel firewall is off AS WELL AS the advanced firewall. I have also just flat stopped the Windows Firewall service on this computer. No combination allows me to telnet on port 1433. I always receive the same error:

C:\>telnet YY.XX.XYX.XY 1433
Connecting To YY.XX.XYX.XY...Could not open connection to the host, on port 1433
: Connect failed

I have badgered the dedicated hosting provider for Server A and they insist that there isn't a router or any other piece of hardware that would prevent outbound 1433 traffic.

Who's lying to me? My Windows server? The hosting company?

Any ideas would be so greatly appreciated!

share|improve this question
    
are all the servers supposed to be on the same subnet and if so are they? –  tony roth Aug 10 '10 at 22:07
    
What version of SQL? Express edition will accept localhost connections, but not from other hosts. –  Chris S Aug 11 '10 at 0:47
    
"I can telnet to Server B on port 1433 from 3 different servers". Are these 3 different servers on the same local network with ServerB and ServerA is not? –  Gennady Vanin Геннадий Ванин Aug 11 '10 at 7:21

7 Answers 7

From your description the problem would appear to be Server A. Start at the beginning. Make sure the Telnet program is in fact successfully sending out packets. I'd be inclined to use Wireshark to verify that.

share|improve this answer

Are Server A and Server B are supposed to be on the same network then? You can verify that there is nothing in the middle with tracert. If Server A is on a different network than the 3 other servers that you've used to telnet into Server B with then it's not really a valid test of connectivity. There could still be firewall rules or router ACL's that prevent connections from Server A's network. Can you ping Server B from Server A or telnet into another port that Server B is listening on?

Put Wireshark on Server A and monitor the connection attempts to see what happens.

Also, have you tried connecting to Server B using SQL tools on Server A? SQL Server Management Studio for example?

(Keep in mind that your outgoing traffic from Server A is actually only destined for port 1433. The source port will be something different.)

share|improve this answer

I would start with some basic network trouble shooting steps.

  1. Can you ping the server?
  2. Can you traceroute to the server? (If so is it passing a firewall that may block the traffic)
  3. Can you telnet to the server from another device on your network segment?

  4. If this does not resolve the problem I recommend something like wireshark to really see what is going on.

share|improve this answer
    
Ping yes, traceroute yes,telnet from another server on Server B's subnet yes. –  marty Aug 11 '10 at 12:51
    
Have you used wireshark before? It sounds like it is time to run (on both ends if possible and hunt down the problem) Although everything seems to point to a firewall on the host. Are you running another program (Antivirus etc) that may be blocking the traffic? –  trent Aug 11 '10 at 14:54

What's different about the three servers that work and Server A that doesn't? Any chance Server B is accepting connections only from certain subnets, for instance?

Failing that, I'd try a telnet from Server A on ANY port, for example to a local SMTP server at the hosting provider on 25. If that works, I'd ask if their support could help you test by setting another of their servers briefly to listen on 1433 - Google "port listener" for examples of free software if they don't have their own.

Once that works, and you've checked that Server B sees inbound connections on other ports from Server A, you'd have some evidence to bring to the Server A hosting support staff.

share|improve this answer
    
Sorry, to clarify Server B and A are in different hosting facilities. As I eluded to I have been able to telnet to server B from 3 other servers in other subnets around the world so I'm pretty confident the issue resides with Server A somehow. –  marty Aug 11 '10 at 12:52
    
So if you can ping B from A, the routing is OK. If you can connect to B on 1433 from 3 other subnets worldwide, it's likely that B is listening to 1433 traffic from A. So either the 1433 packets are not escaping A toward B, or they are but the replies from B (see tcp three-way-handshake) are hitting a wall on the way back to A. If this is important, I'd telnet from A to a temp server C in A's hosting facility...preferably one listening on 1433 as suggested above. This will tell you whether the issue is inside server A (your problem?), or between A and the Internet (provider's problem). –  Paul Aug 11 '10 at 20:28

Does server B have more than one external IP address? SQL Server may not be listening on all the IP addresses. use netstat -n -a to verify that either 0.0.0.0:1433 is there or each external ip address is listed as listening on :1433

Ping from server A and ensure it resolves to the same IP address as your other 3 servers are resolving it to.

If not you will need to reconfigure the sql server networking interface.

share|improve this answer

Can you telnet from Server A to any external port greater than 1024 (on which an external host is listening and permitting to telnet from other hosts)? I believe that default Windows Server have such communications (to ports greater than 1024) closed.

Also, the user under which you run application and which tries to connect to SQL Server should have permission to connect to the Windows NT Named Pipes IPC, \hostname>\IPC$. If the user does not have this permission to connect, then it is not possible to connect to an instance of SQL Server through Named Pipes unless either guest account on the computer is enabled (disabled by default), or the permission "access this computer from the network" is granted to user account.

Though, this depends which common protocols are enabled both in client of MS SQL Server and MS SQL Server.

Thanks for upvoting!

share|improve this answer
    
May I ask why my answer was downvoted? Uncommented downvotes disservice and discredit the community and SF –  Gennady Vanin Геннадий Ванин Aug 15 '10 at 2:40
    
Perhaps a slicker formatting like this will help a bit? Just a thought, and comment-like content may be better as comments so they don't take up too much of the screen real-estate for attempted answers? Though it is hard to put the finger on the exact problem here ^^ –  Oskar Duveborn Aug 15 '10 at 10:47

Can you telnet to localhost on 1433 to ensure the service is listening?

Do you have any other servers in the same data center/cabinet/rack as Server A where you could test locally?

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.