Before we troubleshoot any protocol specific problems, it is important to know that the client can connect to the server computer. For example, if we want to connect to a server called somesvr.org using SSH (port 22), it is best to first assess whether the domain name can be resolved to an IP address:
If dig indicates that the domain name cannot be resolved, or that it cannot contact a DNS server, then that has to be fixed first. Check /etc/resolv.conf to see if valid DNS servers are listed. If the domain name does resolve to an IP address, we can test connectivity using the IP address, such as:
This tests to see if port 22 of the IP address can connect or not. If it connects, it indicates that a daemon/server program is listening on the other side. If not, it can be due to a list of reasons.
First of all, the daemon/server program is not working on the other side. The OS can also have a firewall program that blocks the port. The ISP (internet service provider) can also block certain ports to their client IP addresses.
As a result, it is best to test a client/server configuration on the same subnet that is connected either by a crossover cable, a hub or a simple (non-programmable) network switch. This way, we can rule out the ISP or any other firewall appliance blocking traffic. In Linux, you can use iptables to list firewalling rules:
By default, Debian sets up no firewalling rules. If you see any entries with this command, you should investigate and analyze those rules and see if they explain connectivity problems.