Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am trying to test whether I can get to a particular port on a remote server (both of which I have access to) through UDP.

Both servers are internet facing. I am using netcat to have a certain port listening.

I then use nmap to check for that port to see if it is open, but it doesn't appear to be.

Iptables is turned off.

Any suggestions why this could be? I am eventually going to setup a VPN tunnel, but because I'm very new to tunnels, I want to make sure I have connectivity on port UDP 1194 before advancing.

share|improve this question
I've respondend to the "Testing UDP port connectivity" question. But I suggest to concentrate on the more specific "make sure OpenVPN receives my UDP packets" part - that could be easily achieved by looking at OpenVPN logs. – Luke404 Aug 10 '12 at 12:16
up vote 18 down vote accepted

There is no such thing as an "open" UDP port, at least not in the sense most people are used to think (which is answering something like "ok I've accepted your connection"). UDP is session-less, so "a port" (read: the UDP protocol in the operating system IP stack) will never respond "success" on its own.

UDP ports only have two states: listening or not. That usually translates to "having a socket open on it by a process" or "not having any socket open". The latter case should be easy to detect since the system should respond with an ICMP Destination Unreachable packet with code=3 (Port unreachable). Unfortunately many firewalls could cut those packets so if you don't get anything back you don't know for sure if the port is in this state or not. And let's not forget that ICMP is session less too and doesn't do retransmissions: the Port Unreachable packet could very well be lost somewhere on the net.

An UDP port in the "listening" state could no respond anything (the process listening on it just receives the packet and doesn't transmit anything) or could send something back (if the process does act upon reception and if it acts by responding via UDP to the original sender IP:port), so again you never know for sure what's the state if you don't get anything back.

You say you can have control of the receiving host: that makes you able to construct your own protocol to check UDP port reachability: just put a process on the receving host that'll listen on the given UDP port and respond back (or send you an email, or just freak out and unlink() everything on the host file system... anything that'll trigger your attention will do).

share|improve this answer
Think I'm understanding it now. So a netstat on the server with the listening udp port will never show the remote host... Only a tcpdump should show the remote requests? – Lock Aug 10 '12 at 12:34
Both netstat and tcpdump have the ability to dump data on you, the latter in a more human-readable form. Check out their man pages for details. – Luke404 Aug 10 '12 at 12:38

To test if udp port is responding, use netcat.

An example from the man page:

nc -v -u -z -w 3 20-30
    Send UDP packets to ports 20-30 of, and report which ones
    did not respond with an ICMP packet after three seconds.

Of course, if a firewall is DROPing, which is normally the case when dealing with internet-faced gateways, you won't receive an ICMP response.

share|improve this answer
Thanks. This is what I was looking for! – bmoran May 28 '15 at 15:09

Testing open UDP ports with nmap is fraught with perils -- there's no three-way handshake to indicate openness. Unless the listening process responds to whatever nmap sends, there's no way for nmap to differentiate between an open port that isn't responding and a filtered port.

Much easier is just to listen on one end with netcat and use netcat at the other end to send packets, and see they arrive at the other end. Do it both ways just be sure. You can also tcpdump to see the packets getting to where they need to go.

share|improve this answer
I see.. So how does nmap know an open port exactly? Does it send data to that port and if it receives a response, it is deemed as open? I will use a combination of tcpdump and netcat. Thank you for your well explained answer. – Lock Aug 10 '12 at 8:55

I was having a similar issue and found a good solution using netcat here:

I was able to confirm my UDP port was open and then could proceed to testing my actual code.

share|improve this answer
  1. both on client ans server install nc: yum install nc (for centos)
  2. on server listen UDP port: nc -ul 6111
  3. on client nc -u <server> 6111
  4. type anything on client and hit enter - you should see this text on server
share|improve this answer

You can do this with netcat (nc) or iperf, assuming you have another machine to test with outside the network. My choice would be an nmap UDP scan from a system outside of your environment. What was your nmap command line? Are there any hardware firewalls or other devices in the mix?

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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