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.

  • 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
    Commented Aug 10, 2012 at 12:16

11 Answers 11


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 drop 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.

A UDP port in the "listening" state may not respond at all (the process listening on it just receives the packet and doesn't transmit anything) or it 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 receiving 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).

  • 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
    Commented Aug 10, 2012 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
    Commented Aug 10, 2012 at 12:38

To test if udp port is responding, use netcat.

An example from the man page:

nc -v -u -z -w 3 example.host 20-30
    Send UDP packets to ports 20-30 of example.host, 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.

  • 10
    This response gave me a false-positive, where, in contrast, Sasha's answer exhibits what I expect. Commented Nov 20, 2017 at 18:20
  • 1
    @texas-bronius If you have access to the other server, it's probably better to do Sasha's way
    – motobói
    Commented Nov 22, 2017 at 15:38
  • 1
    I also received a false positive from this example.
    – jlhasson
    Commented Feb 11, 2022 at 16:55
  • 1
    -1: False positive. Given any port number (whether open on server or not), it turns out to be succeeded
    – VanagaS
    Commented Sep 23, 2022 at 20:06
  1. both on client ans server install nc: yum install nc (for centos)
  2. on server listen UDP port: nc -ul 6111 (add the -6 option if you're testing an ipv6 connection)
  3. on client nc -u <server> 6111
  4. type anything on client and hit enter - you should see this text on server

Note: When you run the nc -ul command on the server, it will only connect for the first connection coming to it. You can't, as I found out, switch between servers pinging it without stopping and restarting nc -ul. In fact, if you ^C stop the client (nc -u ...), you also cannot restart the client without first restarting the server listener.

  • 6
    I like this clever answer, because it feeds my own understandings (and misunderstandings!) of how UDP is "send and forget" and all confirmation can only be gotten from proper configuration. Too many factors. This response gives a really simple, definitive call and response which either works or doesn't work, change config, rinse, and repeat. Commented Nov 20, 2017 at 18:20
  • 3
    $ sudo apt install netcat (for ubuntu) Commented Mar 20, 2020 at 14:16
  • 1
    This really should be the accepted answer IMO.
    – cyqsimon
    Commented Mar 29, 2022 at 21:51

I was having a similar issue and found a good solution using netcat here: http://en.wikipedia.org/wiki/Netcat#Test_if_UDP_port_is_open:_simple_UDP_server_and_client

nc -vzu <host> <port>

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

  • 1
    This solution is wrong according to nc man page (last lines): CAVEATS UDP port scans using the -uz combination of flags will always report success irrespective of the target machine's state. However, in conjunction with a traffic sniffer either on the target machine or an intermediary device, the -uz combination could be useful for communications diagnostics. Note that the amount of UDP traffic generated may be limited either due to hardware resources and/or configuration settings. Commented May 5, 2020 at 13:24
  • Always shows success
    – saumilsdk
    Commented Feb 25, 2021 at 9:20
  • good command, faster than other Commented Dec 18, 2023 at 9:51

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.

  • 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
    Commented Aug 10, 2012 at 8:55

You can scan udp ports by using following command

nmap -sU -v <hostname or ip>

From manual:

UDP scan is activated with the -sU option. It can be combined with a TCP scan type such as SYN scan (-sS) to check both protocols during the same run.

UDP scan works by sending a UDP packet to every targeted port. For some common ports such as 53 and 161, a protocol-specific payload is sent to increase response rate, but for most ports the packet is empty unless the --data, --data-string, or --data-length options are specified. If an ICMP port unreachable error (type 3, code 3) is returned, the port is closed. Other ICMP unreachable errors (type 3, codes 0, 1, 2, 9, 10, or 13) mark the port as filtered. Occasionally, a service will respond with a UDP packet, proving that it is open. If no response is received after retransmissions, the port is classified as open|filtered. This means that the port could be open, or perhaps packet filters are blocking the communication. Version detection (-sV) can be used to help differentiate the truly open ports from the filtered ones.


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?


I have a simple-minded approach. If the UDP server does not return expected data, I just stop collecting dgrams, assuming it went down:

LINE: while(1)
    my $line;
    my $flags;

    local $SIG{ALRM} = sub {die "exceeded timeout for recv"};
    alarm 5;
    eval {

    unless($line =~ /\{.*\}/){
            print STDERR "Invalid or empty dgram:\n",'"', $line, '"',"\n";

        last LINE;

Actually if Server listen port 6111 netcat explicitly states it:

# nc -ul 6111
Ncat: bind to :::6111: Address already in use. QUITTING.

You can check a specific UDP port using the following command:

nmap <hostname or ip> -sU -pU:<UDP port>

According to @Zakaria and @Koray answers. Here is what works for me:

  • On Connected port, STATE value is open:
    $ sudo nmap -sU -pU:53
    53/udp open domain
  • On Disconnected port, STATE value will be either closed or open|filtered
    $ sudo nmap -sU -pU:53
    53/udp closed domain

    $ sudo nmap -sU -pU:53
    53/udp open|filtered domain

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .