Emergency UNIX and Linux Support

At this point it could be any number of the things people are saying; or a combination of them.

You're going to have to go down the OSI Model to figure it out. I'd post a link but apparently I need to have five posts first. All this "I have a feeling" stuff is completely useless. Troubleshooting is methodical and logical and not guessing. Troubleshoot from layer 1; the physical layer, first. That means double checking and reseating any of the connections betweent the points. Then check your network config and the server network config. Then verify the "network route" is in place and useable; if your in *NIX route is the same as traceroute in M$. If the results of that don't end up at your server then you have a routing issue. If it does, then you have a software configuration issue. ( For all you "leet" people, I'm going under the premise that not everyone is blocking ICMP like a retard.)

There is also the possibility that the bandwidth at either points is being overwhelmed. I often get that when I try to SSH into my home network from a coffee shop and forget to turn off bittorrent.

...and for things like bittorrent, it's often not really bandwidth that's being overwhelmed as much as the number of simultaneous connections. Distributed file sharing is awful in the way it spams thousands of connections when attempting to find just a few of them, filling the tiny connection tables of a hardware wireless router to the point that for any new connections to be made, an old one must die or timeout first.

Am I missing something here, the original post was back in April?

Someone posted, so it was pulled back to the top. Let's hope the problem was solved in a more timely manner than that. I'd agree though that using ICMP as a test is a bad idea. Protocols aren't treated the same by firewalls, ACLs, etc. and many companies block it to prevent the reverse-enginnering of their network. Using netcat ('nc') or telnet to check the connection is a good first check. Couple that with a good network trace or tcpdump and you can normally find the issue fairly quickly. You can also start another SSH daemon on a port (such as 80/443) not in use that's often allowed by default through all networks and see if you're able to connect there. Start simple and work back up the OSI model.