I have used the following commands

sudo iptables -A INPUT -p tcp --dport 14000 -j ACCEPT
sudo iptables -I INPUT -p tcp -m tcp --dport 14000 -j ACCEPT
sudo service iptables save
sudo iptables -L -n

sudo firewall-cmd --zone=public --add-port=14000/tcp --permanent
sudo firewall-cmd --reload

but port no-14000 is not showing in

netstat -plunt 

First, you should use either iptables or firewall-cmd, not both. If firewalld is running, you should use firewall-cmd, as firewalld will override any changes you might make using the iptables command.

And your firewall-cmd line specifies port 80, not 14000.

Second, a port cannot be open without something actually using it. If you are using a software firewall (either firewalld or raw iptables), you might consider all incoming ports as blocked: your iptables or firewall-cmd commands would unblock the port for use, but not yet actually open it.

To open a port, you would start some process that would actually use the port. For testing, you might use netcat to listen on port 14000:

nc -l 14000

While that command is running, you would see the port as opened in state "LISTEN", But if you then tried to start, for example, a jBoss server configured to use port 14000, it would return an error telling you that port 14000 is already in use (by the netcat command). You would have to stop the netcat command (causing the port to close again) before you could restart the jBoss server in port 14000 successfully: the jBoss server would then be able to open the port for its own use.

In general, when a port is blocked by a software firewall, it completely ignores any incoming connection attempts: if you attempt to telnet to a blocked TCP port, the connection attempt will hang and eventually time out, after a minute or so.

When a TCP port is unblocked but closed, attempting to telnet to it will immediately return a "connection refused" error message.

UDP ports, on the other hand, don't have any standard response: to test connectivity to an UDP port, you must send a request that is properly formatted for that particular UDP-based service, and see if you get a valid response. There can be "one-way" UDP services that don't respond at all: for those, you would have to check the logs at the receiving end to verify that the connection test was successfully received.

  • Now telnet: connect to address Connection refused – observo Dec 9 '17 at 12:12
  • If you don't specify a port number for telnet, it will attempt to use port number 23, the standard port for telnetd service. This service is obsolete and not installed by default. Also, software firewalls usually allow all connections to localhost/ by default, because those connections are internal to the host by definition. If you want to test TCP port 14000, you would do something like telnet 14000 – telcoM Dec 9 '17 at 17:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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