Applications need to communicate between different endpoints. Whether this is a HTTP API, Kubernetes communication between nodes or a VPN tunnel; they all use the network and specific ports to communicate between hosts.
While TCP connections work with a handshake and confirmation of a packet reception (ACK), UDP connections don't offer such a confirmation. To figure out whether or not a firewall is blocking the communication, it makes sense to manually verify the communication over the wanted port(s).
For TCP connections, telnet is a widely used command to quickly verify a working communication:
ck@siteA $ telnet www.geekersdigest.com 443
Trying 104.21.30.181...
Connected to www.geekersdigest.com.
Escape character is '^]'.
But telnet only works for TCP ports. How can UDP communication be tested?
Using netcat to run UDP connectivity tests
Netcat is a very helpful tool and command which exists on Linux, BSD and even on macOS (using brew install netcat). It can open TCP connections, send UDP packets, listen on arbitrary TCP and UDP ports, do port scanning, and
deal with both IPv4 and IPv6.
Let's assume the following situation: Site A needs to access Site B on UDP port 52000. With netcat installed on two hosts on either site, we can use the -l parameter to listen on our needed UDP port on Site B. Another important parameter is -u, to tell netcat to use UDP. This is called the "server/listener side":
ck@siteB $ nc -l -u 52000
That's it, you won't get a confirmation from netcat that the port is now opened or listening. Just a "new line" indicating that the command is still running.
Now we can attempt the connection from Site A to Site B using UDP port 52000. This is called the "client side":
ck@siteA $ nc -u siteb 52000
Same situation as before: A new line just below the entered command shows up.
Does that mean the communication is established? Not for sure. Even if a firewall between the two sites is blocking, the output of the netcat commands on both sides will look like this. The only way to find out, is to send data from one side to another:
Just by entering some text on either side and hitting the [ENTER] key, the data is sent to the other side. If the communication works, the entered text will appear on the other side.
Voilà, successful UDP communication!
nc, ncat or netcat?
You might have noticed that some articles mention the nc and others netcat as command on the Terminal.
On Debian-based distributions (Ubuntu, Linux Mint, …) several netcat packages are available:
ck@mint ~ $ apt search netcat
p netcat - TCP/IP swiss army knife -- transitional package
v netcat:i386 -
i netcat-openbsd - TCP/IP swiss army knife
p netcat-openbsd:i386 - TCP/IP swiss army knife
p netcat-traditional - TCP/IP swiss army knife
By default, the newer "netcat-openbsd" package is installed. This refers to the nc command. The netcat command is a symlink pointing to nc.
After the installation of the "netcat-traditional" package, the additional nc.traditional command is available. For a UDP communication test it works the same way as the nc command.
ck@mint ~ $ sudo apt install netcat-traditional
ck@mint ~ $ nc.traditional -l -u -p 52000
One more alternative is the "ncat" package. This is yet another netcat fork from the nmap project. Similar to the other two netcat commands, ncat works the same way for testing a UDP communication:
ck@mint ~ $ sudo apt install ncat
ck@mint ~ $ ncat -l -u -p 52000
On Rocky Linux 9 the default netcat command is ncat. nc itself is a symlink to ncat. The same possibly applies to other Enterprise Linux (EL) distributions.