Testing Remote TCP/IP Connectivity
We frequently need to confirm connectivity between systems on particular ports.
telnet
The simplest way to do this is with the telnet command. The syntax is:
telnet <server> <port>
Failure
One kind of failure looks like this:
telnet <server> <port>
Trying...
telnet: connect: Connection refused
This typically means that the connection reached the destination server, but nothing was listening on that port. It’s also possible that it means some firewall between the two systems is flat-out rejecting the request.
Another like this:
telnet <server> <port>
Trying...
… after a notable delay, eventually you’ll get …
telnet: connect: Connection timed out
This means a firewall isn’t letting the connection through, or possibly that the remote system isn’t routing correctly back to the originating system
Success
And success looks like this:
telnet <server> <port>
Trying...
Connected to <server>
Escape character is '^]'.
On any system that has telnet installed, this seems to be the simplest approach.
ssh
Some Linuxes, including at least RHEL, apparently do not have telnet installed by default. Presumably because it’s insecure if you login with it. Regrettably, that means you can’t perform the above connectivity test with it, which is not itself insecure.
If you’re unable or not allowed to install the telnet client, the ssh command has a similar way to attempt a connection on a particular port. Regrettably, its success/failure is more unclear (to me). The syntax is
ssh <server> -p <port>
Failure
One kind of failure looks like this:
ssh <server> -p <port>
ssh: connect to host <server> port <port>: Connection refused
I believe this can happen either when a firewall is rejecting the connection or when the connected server is not listening on the requested port.
Another kind of failure looks like this:
ssh <server> -p <port>
… Followed by just sitting there doing nothing.
I believe this means some firewall isn’t letting you through but isn’t actively rejecting the connection either. We saw this when the first firewall out of our origination system was allowing us through but the second one into our destination system was not.
Success
Regrettably, best I can tell, Success looks exactly like the second failure scenario. That is,
ssh <server> -p <port>
… Followed by just sitting there doing nothing.
You’re connected and can type (appropriate) commands to the connected system, but there’s no indication that you’re connected.
Thus, I really don’t like using ssh to test connectivity. It can prove immediate problems via the first kind of failure, but when that doesn’t occur doesn’t give me confidence that the connection truly worked.
openssl
This seems a better alternative to ssh, but is more cryptic to remember. Its syntax is:
openssl s_client -connect <server>:<port>
Failure
Either:
openssl s_client -connect <server>:<port>
socket: Connection refused
connect:errno=111
Or:
openssl s_client -connect <server>:<port>
… after a notable delay …
connect: Connection timed out
connect:errno=78
Success
Success gives definitive feedback:
openssl s_client -connect <server>:<port>
CONNECTED(00000003)
4398003263296:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:766:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 263 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---