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: Linux / Windows

6 Answers 6


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
  • 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
    Commented Apr 26, 2013 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
    Commented Apr 26, 2013 at 16:01
  • I know the question was regarding Solaris 10, but as a FYI, v11 has netcat available in the repo. Commented Mar 3, 2017 at 19:50

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). The details of the message1 depend on how the firewall is configured, but "port unreachable" is probably the most common.

"No route to host" may indicate this, but it may also indicate more subtle routing issues.

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.

  1. E.g., "port unreachable", "host prohibited", various other combinations of host/port/admin and unreachable/prohibited; look for these in the message as they are an explicit indication of an IP firewall in play.

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


$ 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       *                   LISTEN      -                   
tcp        0      0     *                   LISTEN      -                   
tcp        0      0        *                   LISTEN      -                   
tcp        0      0     *                   LISTEN      -                   
tcp        0      0     *                   LISTEN      3034/dropbox        
tcp        0      0     *                   LISTEN      3033/dropbox        
tcp        0      0    *                   LISTEN      3191/ssh                       
tcp        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 ( 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.

  • 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
    Commented Apr 26, 2013 at 13:54
  • 1
    Solaris's motto ought to be "Nothing is ever just easy."
    – Bratchley
    Commented Apr 26, 2013 at 13:58

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

What you can do is try it from server2:

nmap server1
  • Thanks for your help. Unfortunately this command not there in Solaris (or not installed). I am getting "nmap: command not found"
    – yottabrain
    Commented Apr 26, 2013 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
    Commented Apr 26, 2013 at 13:05
  • @user1734143 it's available via OpenCSW, which you should probably install anyways, makes your administrative experience A LOT easier.
    – Bratchley
    Commented Apr 26, 2013 at 13:40

Recently I've got the same request and came to the thread. I was able to scan open ports on the FW with the nc command, like this as I query its output:

nc -v -w 1 -z -s *srcIP destIP port* 2>&1 | grep timed > /dev/null && echo closed || echo open

Basically, if I get 'timed out' it means that the port is not open on the FW.


You can use an online tool such as www.firewallruletest.com to see if external hosts can establish tcp connections.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .