13

I have here a dilemma. I have a device that communicates to another remote device but there is a firewall between them. It's a UDP connection, so TCP utilities don't work to test if the specific port is open. I know that we could get that from the firewall but I don't have access so I have to prove that the port is not open.

The source system is a Windows 7 system and the destination system is a appliance running Linux.

  • 1
    Without access to the firewall, you really can't tell (unless, of course, your systems are working). – Ron Trunk Feb 4 '16 at 20:46
  • Questions involving networks over which you have no control are explicitly off-topic here. – Ron Maupin Feb 4 '16 at 21:00
  • 2
    I would vote to leave it open. I think this falls into the grey area, and it's a useful theory/troubleshooting question. – Ron Trunk Feb 4 '16 at 23:18
  • 1
    ...do you have control of the firewall and networks? If not, then this is off topic here. – Craig Constantine Feb 5 '16 at 13:11
  • This is by a now a lab environment, we are trying to simulate a future production situation. I would like to get a way to troubleshoot UDP sessions without have to parse logs on the server side. But thanks I believe that is not possible by the nature of the type of communication. – JoeliNNaBit Feb 11 '16 at 17:11
10

UDP is obviously a send-and-forget protocol. For example, during an NMap UDP scan, the only way to definitively prove that a UDP port is open is if you receive a response from that port. Keep in mind that many services may not reply to arbitrary data and require protocol or application-specific requets in order to warrant a response. Certain ICMP codes can gurantee that the port is closed, however. RFC 792 and RFC 1122 give us some good information as to what to expect when a port is closed.

For example, an ICMP type 3 code 3 "Destination Port Unreachable" is, for all intents and purposes, almost guaranteed to be a closed port.

A full list of codes can be found here:
http://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml

  • 1
    Thanks for the answer. I will investigate more about ICMP type 3 requests. – JoeliNNaBit Feb 11 '16 at 17:26
7

This is a quick recipe:

1) Start a packet sniffer:

sudo tcpdump -n -i eth2 icmp &
[1] 1409
$ tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 262144 bytes

2) Send an UDP packet:

$ echo reply-me | nc -u 1.0.0.2 1000

3) If you receive 'ICMP port unreachable', that UDP port is closed:

20:54:15.475211 IP 1.0.0.2 > 1.0.0.1: ICMP 1.0.0.2 udp port 1000 unreachable, length 45

4) Otherwise, usually either the port is open or something is blocking ICMP.

  • 1
    Since the source system is Windows 7, the Linux commands won't work. – Ron Maupin Feb 5 '16 at 21:20
  • 1
    Yes that's true but I will try to a virtual machine and check if it works. – JoeliNNaBit Feb 11 '16 at 17:16
4

"nc -uvz ip port" isn't somehow accurate, you probably should use "nmap -sU -p port ip", if the result shows "open" then the udp port probably is open, if it shows "open|filtered" then probably it is closed or filtered.

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