Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Somehow I have been charged with the task of organizing the installation of a new production environment involving 4 servers.

I have to make requests to the Network administrator to open up ports on the firewall. He says he has made the changes and I need to check them.

I need to check that:

1 server alpha will be able to SFTP to server beta.

2 server alpha will be able to connect to LDAP on server gamma 636.

3 server alpha will be able to view webservices on server delta port 80

The best way I know how to do this is to try to telnet to the server, so for example for situation #1 I tried logging into alpha and :

alpha> telnet beta.mycompany.com 22

Is there a better way to test if I can connect on ports 22, 636 and 80?

share|improve this question

migrated from stackoverflow.com Jan 24 '11 at 21:46

This question came from our site for professional and enthusiast programmers.

add comment

2 Answers

It really depends on what level of verification you're looking for. For most simple single port TCP services (such as those listed), you just need to verify that the port is open and accepting connections. The easiest method would be to use nmap. Specific syntax for checking the ports mentioned would be:

nmap -p 22,80,636 192.168.1.1

And would return a result along the lines of:

Starting Nmap 5.00 ( http://nmap.org ) at 2011-01-24 16:20 CST
Interesting ports on 192.168.1.1:
PORT    STATE  SERVICE
22/tcp  open   ssh
80/tcp  open   http
636/tcp closed ldapssl

Nmap done: 1 IP address (1 host up) scanned in 0.23 seconds

If the firewall were blocking any of those ports, the STATE returned would be filtered instead of open or closed.

That only verifies the firewall rules, though. It doesn't verify that the service is necessarily running on the port, or that it is operating correctly. For that, you'd have to run a check that understood the service you were checking.

share|improve this answer
add comment

Assuming that the services are "listening" on the destination servers using a TELNET client to test TCP connectivity is a perfectly valid method. You can use a tool like "netcat" if you want to get even more bare-bones. You're just testing up the stack to TCP this way. You can't guarantee that the layer 7 protocol is actually working w/o doing more.

If you want layer 7 verification, use a client program for each of the protocols in question and attempt to perform some type of client / server interaction from the machines that will be sourcing the connections.

As always, if you're in doubt about whether your traffic is making it where you'd expect it to go I'd recommend using a sniffer (tcpdump, Wireshark, etc) to verify that the packets really are ending-up where you expect them to. There's no substitute for watching the bits on the wire.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.