Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

We will be deploying a new application to a Server and the application will be listening on port 8443. We have asked Network team to open the firewall for the port 8443 on that server before deploying the application. There is no application currently listening on that particular port on the server.

Is there anyway i can make sure the firewall is opened for the port 8443

OS: Solaris 10 10/09 s10s_u8wos_08a SPARC

share|improve this question

4 Answers 4

If you want to see if you can form a TCP connection from a remote machine, get OpenCSW installed on that and the target machine, and install netcat on both. This is the syntax for using netcat to test TCP connections:

nc -vz targetServer portNum

For example to check SSH on "homeServer1":

nc -vz homeserver1 22

That enables you to test TCP-level connectivity from the remote system. Netcat can also be configured to listen on a port rather than act as a client. To get it to listen on TCP/8443:

On the server that will house the application: nc -l homeserver1 8443

On a machine that sits outside the firewall: nc -vz homeserver.fqdn 8443

This is an example of a successful execution:

[jadavis6@ditirlns01 ~]$ nc -vz ditirlns01.ncat.edu 8443

Connection to ditirlns01.ncat.edu 8443 port [tcp/pcsync-https] succeeded!

A failed execution:

[jadavis6@ditirlns01 ~]$ nc -vz ditirlns01.ncat.edu 8443

nc: connect to ditirlns01.ncat.edu port 8443 (tcp) failed: Connection refused

share|improve this answer
    
This does not (quite) resolve the question of whether a firewall is blocking the port. It seems that nc reports "Connection refused" when the port is accessible, but there is no listener, and "Network is unreachable" when the request has been bounced by a firewall via icmp (meaning there may or may not be a service on the port). If the firewall drops the packet instead of actually rejecting it, nc will just hang for a while. –  goldilocks Apr 26 '13 at 15:58
    
Well my goal with the last netcat command was just to provide an example of what successful execution and unsuccessful execution to help them interpret any results on their end if it was unclear to them for some reason. The part that answers their question is the first "On a machine"/"On the server" part. –  Bratchley Apr 26 '13 at 16:01

Firewalls should reply with an ICMP message when they block a request. However, this is not necessarily the case (you will be interested in this nice article).

You can test from the outside to see whether a port is accessible through a firewall and, if so, whether anything is listening on it. Here's three different scenarios involving a tcp request which you can observe with wireshark, or some other packet sniffer, and what you'll see:

1) Firewall rejects request

You get an ICMP message back, and the tool making the request should immediately tell you something to this effect ("unreachable, admin prohibited" etc). By "tool" I mean the client you are using to send the request (I used telnet).

2) Firewall drops packet

There is no reply, so the tool waits until it times out or you get bored.

3) Firewall allows packet (or there is no firewall), but nothing is listening on the port.

You get a TCP RST/ACK message back. I presume the TCP protocol requires this. In other words, if nothing is listening on the port, the OS itself sends this reply. It may be difficult to distinguish this from #1 just based on what a tool reports, because it may say the same thing in both cases (however, most probably do distinguish this as "connection refused" vs. #1, "network unreachable"). Observed in a packet sniffer on the client machine, scenario #1 (ICMP reject message) and #3 (TCP RST/ACK message) are clearly distinct.

The only other option here is that the packet is allowed through by the firewall and something is listening, so you get a successful connection.

In other words: presuming your networking in general works properly, if you get #1 or #2, it means a firewall is actively preventing access to the port. #3 will happen if your server is not running but the port is accessible, and of course (the implicit) #4 is a successful connection.

share|improve this answer

The configuration and the status of the firewall configuration is firewall/OS specific.

What you can do is try it from server2:

nmap server1
share|improve this answer
    
Thanks for your help. Unfortunately this command not there in Solaris (or not installed). I am getting "nmap: command not found" –  user1734143 Apr 26 '13 at 13:03
    
@user1734143 it is probably in the "repositories" or the Solaris equivalent, but anyway you can download it, and even compile it from here –  RSFalcon7 Apr 26 '13 at 13:05
    
@user1734143 it's available via OpenCSW, which you should probably install anyways, makes your administrative experience A LOT easier. –  Bratchley Apr 26 '13 at 13:40

You can use the command netstat to see if a port is open and listening.

Example

$ netstat -anp | less
Active Internet connections (servers and established)

Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name   
tcp        0      0 0.0.0.0:111                 0.0.0.0:*                   LISTEN      -                   
tcp        0      0 0.0.0.0:41716               0.0.0.0:*                   LISTEN      -                   
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN      -                   
tcp        0      0 127.0.0.1:631               0.0.0.0:*                   LISTEN      -                   
tcp        0      0 0.0.0.0:17500               0.0.0.0:*                   LISTEN      3034/dropbox        
tcp        0      0 0.0.0.0:17501               0.0.0.0:*                   LISTEN      3033/dropbox        
tcp        0      0 127.0.0.1:2143              0.0.0.0:*                   LISTEN      3191/ssh                       
tcp        0      0 127.0.0.1:2025              0.0.0.0:*                   LISTEN      3191/ssh 

The output shows processes (column farthest to the right) that are listening on TCP ports. The port numbers are the numbers that follow the colons after the IP addresses (0.0.0.0:111 would be port 111 for example).

The IP addresses show Local and Foreign Addresses. Local would be your system while Foreign would be any addresses either connecting to your TCP port or you connecting to one of their TCP ports.

So in the case of port 22, that's the ssh daemon running on my system, that's LISTENING for connections. Once someone attempts to connect to the ssh daemon it forks a copy of itself and pushes that connection off to another port, keeping TCP port 22 open for additional connections as they come in.

share|improve this answer
    
Just an FYI that netstat syntax is very GNU-specific, this is the closest equivalent that works natively on Solaris: netstat -a -P tcp -f inet | awk '/LISTEN$/ {print $0}' –  Bratchley Apr 26 '13 at 13:54
    
Solaris's motto ought to be "Nothing is ever just easy." –  Bratchley Apr 26 '13 at 13:58

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.