37

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 Aug 10 '12 at 12:16
43

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

  • 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
54

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.

  • 1
    This response gave me a false-positive, where, in contrast, Sasha's answer exhibits what I expect. – texas-bronius Nov 20 '17 at 18:20
  • @texas-bronius If you have access to the other server, it's probably better to do Sasha's way – motobói Nov 22 '17 at 15:38
24
  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

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.

  • 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. – texas-bronius Nov 20 '17 at 18:20
10

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 Aug 10 '12 at 8:55
9

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.

2

You can scan udp ports by using following command

nmap -sU -v <hostname or ip>
1

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?

1

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 {
        $socket->recv($line,2024,$flags);
    };

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

        last LINE;
    }
}

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.