I'm trying to verify that a couple of our servers can communicate via certain ports before migrating some of our services to them, and that they're not blocked by our organizations firewall ACLs.

Makes Sense

[mrduki@mybox1~]$ nc -ul 40000
[mrduki@mybox2~]$ nc -zvuw2 mybox1.com 40000
Connection to mybox1.com 40000 port [udp/*] succeeded!

Doesn't Make Sense

[mrduki@mybox1~]$ nc -ul 40000
[mrduki@mybox1~]$ ^C
[mrduki@mybox2~]$ nc -zvuw2 mybox1.com 40000
Connection to mybox1.com 40000 port [udp/*] succeeded!

In fact, if I do a port scan from 40000-40100, every single port succeeds.

If I do the same tests without -u (so that it tests TCP instead of UDP), I get 40000 (tcp) timed out: Operation now in progress errors, as I would expect (since I have no such TCP service listening on 40000).

Doing a sudo netstat -alnp | grep LISTEN on mybox1 though shows no such services listening on these ports. So what am I missing?

3 Answers 3


nc may not be the best tool for testing port status. Have you tried nmap? It's actually a port scanner. I checked a file server on my home network and, both report that UDP port 40000 is closed.


# nmap -sU -p 40000 igor

Starting Nmap 7.01 ( https://nmap.org ) at 2016-08-18 18:27 EDT
Nmap scan report for igor (
Host is up (0.00027s latency).
rDNS record for igor.swass
40000/udp closed unknown
MAC Address: 68:05:CA:3A:BF:B7 (Intel Corporate)

Nmap done: 1 IP address (1 host up) scanned in 0.53 seconds

Kernel + /dev

You can also use the kernel to do this like so. But nmap is probably better.

# timeout 3 cat < /dev/udp/example.com/40000

When I tried nc on the same server (igor) I was getting the same results as you. But I went back to try again, and now it returning no output (no succeeded message) and wireshark is showing "Destination unreachable" being sent back over ICMP. I don't understand any of this. But I'd switch to a different method of checking UDP port status.

  • Ok, but why is nc not the best tool for the job? I also suddenly have this issue, except that nc is reporting connection succeeded for literally any port I test on any server, except localhost. I cannot imagine why it would do this. Sep 9, 2020 at 1:34

UDP is a "connectionless" protocol. If you send a packet and you don't get a rejection (via ICMP), regardless of whether you get a reply or not, it's considered successful. Something quite common is a firewall blocking the target's ICMP rejection packets from being sent back to you (which is what netcat uses to know whether the port is closed, otherwise it thinks it's open).

Contrast this with TCP, which is statefull. A failure to receive a reply (ACK) is considered a failure within TCP (this usually shows up as "filtered"), as are negative replies (RST, which will show up as closed).

UDP: open|filtered closed TCP: open closed filtered


No firewall block will stop a UDP connection attempt from succeeding since connecting with UDP doesn't involve sending anything or listening for any responses. Functionally, a UDP connect operation is the same as a send up to the point where data is actually sent, that is, it:

  1. Ensures the selected local port can be bound to, if one was selected.
  2. If no local port was selected, it chooses one.
  3. Locks the endpoint so that it, by default, will communicate with the selected IP and port and discard any datagrams received from any other IP address or port.
  4. The system may change the way it handles some types of errors.
  5. That's it.

Notice that none of this does anything a firewall would interfere with, nor is anything sent on the wire.

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.