17

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.

tshepang
  • 109
  • 4
JoeliNNaBit
  • 171
  • 1
  • 1
  • 4
  • 1
    Without access to the firewall, you really can't tell (unless, of course, your systems are working). – Ron Trunk Feb 04 '16 at 20:46
  • Questions involving networks over which you have no control are explicitly off-topic here. – Ron Maupin Feb 04 '16 at 21:00
  • 3
    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 04 '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 05 '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
  • Unfortunately, questions about networks that you do not directly control are off-topic here. – Ron Maupin Jan 31 '18 at 15:05

3 Answers3

13

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 requests in order to warrant a response. Certain ICMP codes can guarantee 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

Community
  • 1
Goodies
  • 445
  • 3
  • 17
  • 1
    Thanks for the answer. I will investigate more about ICMP type 3 requests. – JoeliNNaBit Feb 11 '16 at 17:26
  • @JoeliNNaBit Also check this C code example on detecting ICMP response. https://stackoverflow.com/questions/60649653/check-if-udp-port-is-open-with-icmp-in-c . – Rick Aug 02 '22 at 06:46
13

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.

Everton
  • 1,636
  • 12
  • 24
6

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

Jailman Tough
  • 61
  • 1
  • 1