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.

closed as off-topic by Ron Maupin Jan 31 '18 at 15:05

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "NE is a site for to ask and provide answers about professionally managed networks in a business environment. Your question falls outside the areas our community decided are on topic. Please visit the help center for more details. If you disagree with this closure, please ask on Network Engineering Meta." – Ron Maupin
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 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

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:

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

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 1000

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

20:54:15.475211 IP > ICMP 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

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