How to check whether firewall opened for a port but not listening on the port
Solution 1
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
Solution 2
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.
- 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.
Solution 3
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.
Solution 4
The configuration and the status of the firewall configuration is firewall/OS specific.
What you can do is try it from server2:
nmap server1
Solution 5
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.
Related videos on Youtube
yottabrain
Updated on September 18, 2022Comments
-
yottabrain over 1 year
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
-
yottabrain about 11 yearsThanks for your help. Unfortunately this command not there in Solaris (or not installed). I am getting "nmap: command not found"
-
RSFalcon7 about 11 years@user1734143 it is probably in the "repositories" or the Solaris equivalent, but anyway you can download it, and even compile it from here
-
Bratchley about 11 years@user1734143 it's available via OpenCSW, which you should probably install anyways, makes your administrative experience A LOT easier.
-
Bratchley about 11 yearsJust 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 about 11 yearsSolaris's motto ought to be "Nothing is ever just easy."
-
Bratchley about 11 yearsWell 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.
-
sleepyweasel about 7 yearsI know the question was regarding Solaris 10, but as a FYI, v11 has netcat available in the repo.