1

I need to connect from a Debian GNU/Linux webserver to an SQL Server database which is hosted on a Windows machine within an organization's local network.

The person in charge of the database server and the person in charge of the firewall both say they've setup everything so that I should be able to connect: incoming connection allowed on the database server, incoming connection allowed and port forwarding enabled (1433 TCP and 1434 UDP) on the firewall. They've allowed the webserver's IP and still I can't connect to the database. I can't even initiate a TCP connection to port 1433 either using telnet or nc. I've run nmap on the firewall but it's not reporting those ports as open. For testing, the person managing the database machine has asked the person managing the firewall to allow his own IP and he can connect just fine. I've also asked the webserver hosting company to check outgoing connection to those ports and they've explicitly allowed it.

Am I right in thinking that before looking for a problem with FreeTDS, I should be able to make a raw TCP connection to port 1433?

Is it possible that SQL Server does something unusual with its network implementation and that my tests using telnet, nmap or nc aren't relevant in this case?

Is it possible that nmap is not reporting ports as open when they're actually open?

Alex Marandon
  • 115
  • 1
  • 6

2 Answers2

3

telnet has always been the canary in the coal mine for me regarding connectivity. You're right in that you should be able to telnet to the port. You can't do much from there, but that will tell you at least whether all the moving parts are in place for you to be able to communicate over that port. Good luck!

Ben Thul
  • 2,969
  • 16
  • 23
2

If someone can connect using the native SQL Server tools via port 1433 (you only need UDP 1434 if you are using a named instance) and you can't from the linux server it's a firewall. I use telnet all the time to verify connectivity.

mrdenny
  • 27,074
  • 4
  • 40
  • 68