Fog Creek Software
Discussion Board

Networking question

I'm offsite and now I'm not able to connect to my remote SQL Servers or use Terminal Services to connect to my servers.

I've looked through the router and I can't see where it's blocking any ports, but to be safe I punched a hole for the ports that I need.

Still, I'm not able to connect. How do I go about "debugging" this? If I were having problems connected to the servers, I might use tracert, but how do I figure out where the port is being blocked?

Friday, July 9, 2004

> but to be safe I punched a hole for the ports that I need

It really depends on the brand of the drill bits.

Li-fan Chen
Friday, July 9, 2004

In addition to not blocking any ports, is your router forwarding the ports to the correct server(s)?

Friday, July 9, 2004

As far as I know, you only need to
- open TCP 3389 on the router and firewall,
- if the TS is not in your DMZ, and thus, not reachable directly through a public IP, you need to make sure that packets are correctly forwarded to the TS server in your private network, and
- that you have a valid user account on the TS server.

To test all this, first log onto the TS server directly on the console to check that the account is valid, and next, from home, telnet to 3389 to see if you can connect.

Friday, July 9, 2004

Well, the slammer worm used ports 1433 and 1434 to attack SQL servers world wide. Those are the standard ports that SQL Server communicates to the world with. I suspect every ISP with two or more braincells to rub together has blocked those ports.

Take a look with the SQL Server Client Network Utility (start, programs, m$ $ql $erver, client network utility). Make sure you havev tcp/ip enabled as a protocol, and that it has a higher order than named pipes (named pipes are not very routable). Most issues with connecting to the sql server, that I have found, involve inappropriate protocol useage.

Friday, July 9, 2004

Clever peter, did you think up those $ $igns all on your own?

Friday, July 9, 2004

There's so many ways to set up networks and so many differences between vendors that it's hard to give any concrete advice.

Does any of your networking equipment have logging capab ilities? Is there a log on the router that you can confirm recieved the packet? For the individual computers involved in your network, you can install a packet sniffer like Ethereal to monitor what traffic is going to/through them.

But I don't believe that there is any way to walk a packet (other than ICMP packets, I guess) through the network and see where it gets dropped. That is, there's no way to do it from the source computer alone. You need to put in a monitor at each computer (that you have access to) that you expect the packet to pass through and track it the hard way.

Bill Tomlinson
Friday, July 9, 2004

tcptraceroute can trace a TCP packet to any port, seeing where it gets dropped. In the unlikely event that's what's happening it might help the original poster... if they have access to a Unix machine.

Nate Silva
Friday, July 9, 2004

*  Recent Topics

*  Fog Creek Home