First, you should use either
firewall-cmd, not both. If
firewalld is running, you should use
firewalld will override any changes you might make using the
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
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.