This actually came up at work today and I work at a very large organization that manages a large enterprise of machines. Basically some people who I struggle to call "Engineers" or even "Professionals" needed a way to test if certain ports are allowed through a firewall from two separate networks.

Their solution was to use portqry, which is a little tool made by Microsoft that allows you to make arbitrary connections to whatever port you want using TCP and UDP protocols. There's nothing inherently wrong with portqry, it works just fine and it will tell you when you've connected to a TCP port on a remote machine. However with UDP, portqry's best answer it can give you is ¯\(ツ)/¯ "I dunno".

If you don't know why this is the case I can explain it if you want to listen. Just keep in mind this is all very overly simplified and I encourage you to do your own research. But here we go

How TCP works

Very simply, the TCP protocol cares that your data reaches the endpoint so there is a series of requests, requests for acknowledgement, and acknowledging these requests and verifying the last 1500bytes got there. Here are some diagrams that will explain this. Hope fully these are easy enough to read, but if not they are linked to the original image that you can see in better detail.

As you can see there's not only a lot of actual data going back and forth there is also a lot of preparation to send the data and a lot of making sure the data got there. This is how you can download that really good quality mp3 from itunes because your machine and the itunes server makes sure you get every bit of that mp3. This is in contrast to how UDP works.

How UDP Works

UDP is often called a "connection-less" protocol because there is not solid connection made between you and the server on the other end. With UDP the client just throws data at the server in hopes that the data gets there. Again see the diagram below.

Notice that there is no acknowledgement that the server got the logs, it is just accepting them at full speed and your client has to trust that the data it is sending reached then endpoint. That is an example using a service (syslog) that not everyone uses or cares about. Lets look at an example using a service that everyone cares about DNS (Domain Name Service). DNS is the reason that typing steemit.com into your web browser actually takes you to the steemit website. DNS translates the domain name into an ip address so your machine knows where to send its packets. See below for a diagram.

So this seems kind of important right? Wouldn't we want to make sure that we get a DNS response and wouldn't we want to make sure that the response is getting back to the client? So lets take a theoretical look at what DNS would look like going through TCP.

That is a lot more steps. Waiting for those steps to complete takes time and I can't wait that long when I'm refreshing my latest steemit post to see how many cents I've made. The worst that could happen with a DNS request is that your client forgets what the ip address was for the host. If it does then another DNS request is very quick to do. Also to mitigate the risk of not being able to resolve addresses, your machine caches requests it has already made to cut down on the amount of requests.

Why scanning UDP ports is dumb and what is a better way.

So I hope you've realized at this point that if you just try to make an arbitrary connection to a UDP port you're not going to get anything in return. There's nothing on the other end that is going to answer you for just sending it a network packet. This is what port scanners do, they send a packet of random data to a port to see what comes back, if anything. Since UDP doesn't send back anything unless specifically asked (like DNS) you won't be able to tell if the port is open from the client this way. So what is a better way?

The better way is to understand what services use what ports and protocols. You want to make sure you make DNS requests to a server through a firewall? Just actually make a DNS request. Open a web browser and go somewhere. If you can get there then your client has made a DNS request and it was successful. If you want to get more granular and make sure you're asking a specific server for a DNS request, use tools like nslookup.

So actually try to use the service for what its job is and tell people that scanned a machine to see if UDP port 53 was open that they are dumb. Thanks.

--Veemun