Blocked ports? How to test networks with Ncat

Why do firewalls block ports without warning?

When an application fails to communicate with another over the network, the first suspect is usually the firewall, the security system that decides who enters and leaves a server. In practice, this means a data packet sent by you hits the destination port and encounters an invisible wall, often generating only an awkward silence instead of a clear error warning. For developers and system administrators, figuring out whether the issue is a closed port, a stopped service, or a restrictive network rule can turn into a frustrating investigation.

Traditional tools like the famous ping command only check if the remote computer is turned on in the network, but they are completely blind to specific ports. Knowing the server responds on the network is useless if your database or web application port is tightly locked. Exactly in this scenario, Ncat comes into play, serving as a modern evolution of the classic Netcat utility, allowing you to open arbitrary connections, test sockets, and manipulate raw traffic directly from the terminal.

What is Ncat and why use it instead of legacy Netcat?

The original Netcat was dubbed the Swiss Army knife of network administrators decades ago, but it fell behind and left important security gaps. Ncat was born within the Nmap project to fix these flaws, bringing native support for encrypted connections with SSL and TLS, refined control over allowed IP addresses, and a much more consistent syntax. In practice, it works as a tool capable of reading and writing data across network connections using the TCP and UDP protocols.

When you need to simulate a service listening on a specific port or fire packets to check if traffic is flowing, Ncat solves the problem with just a few lines of command. Before applying complex infrastructure changes or blaming the security team for a lack of connectivity, it pays to audit network nodes, much like we do when auditing exposed keys or checking secrets with code auditing tools to ensure the environment is clean and accessible.

How to test open TCP ports on remote servers

The most common test in daily support and network engineering involves checking whether a TCP port is accepting connections on a remote machine. The TCP protocol ensures that data arrives in the correct order and without errors, establishing a three-way handshake before transmitting anything. To check if port 80 on a server is open, we can use Ncat in simple connection mode by specifying the target IP address and port.

The command below attempts to connect to the desired IP address on the specified port:

ncat -zv 192.168.1.50 80

In this command, the 'z' flag tells Ncat not to send any actual data, just scan the port, while 'v' turns on verbose mode to show what is happening on the screen. If the port is open and free of blocks, the terminal will return a message confirming the success of the connection, proving that the pathway firewall allowed the TCP packet to pass.

Diagnosing UDP traffic and its pitfalls

Testing UDP ports tends to be much more frustrating than testing TCP ports, and the reason is simple: the UDP protocol does not perform a prior confirmation handshake. It simply packages data and fires it toward the destination, not caring if anyone is listening on the other side. In practice, this means if you send a test command to a closed UDP port, the remote server might simply drop the packet instead of sending a rejection notice.

To work around this limitation and get a reliable response, we need to send a payload of data that forces the remote application to react. Here is a practical example of sending a UDP message:

echo