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.

Improve this question
6
  • 1
    Without access to the firewall, you really can't tell (unless, of course, your systems are working).
    – Ron Trunk
    Commented Feb 4, 2016 at 20:46
  • Questions involving networks over which you have no control are explicitly off-topic here.
    – Ron Maupin ♦
    Commented Feb 4, 2016 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
    Commented Feb 4, 2016 at 23:18
  • 1
    ...do you have control of the firewall and networks? If not, then this is off topic here.
    – Craig Constantine
    Commented Feb 5, 2016 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
    Commented Feb 11, 2016 at 17:11

3 Answers 3

Reset to default
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.

Improve this answer
2
  • 1
    Since the source system is Windows 7, the Linux commands won't work.
    – Ron Maupin ♦
    Commented Feb 5, 2016 at 21:20
  • 1
    Yes that's true but I will try to a virtual machine and check if it works.
    – JoeliNNaBit
    Commented Feb 11, 2016 at 17:16
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

Improve this answer
2
  • 1
    Thanks for the answer. I will investigate more about ICMP type 3 requests.
    – JoeliNNaBit
    Commented Feb 11, 2016 at 17:26
  • @JoeliNNaBit Also check this C code example on detecting ICMP response. stackoverflow.com/questions/60649653/… .
    – Rick
    Commented Aug 2, 2022 at 6:46
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.

Improve this answer
1
  • This is the best command by far which gives the status as you need.
    – Raymond
    Commented Sep 18, 2022 at 10:45

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