Share via

Detecting port availability and blockage: Part 1, The Players

  • Article

Note: For Part 2 of this blog, "The trace", Click Here

In a recent blog "Welcome to the domain, just kidding", I referenced RPC port 135 was being blocked as the root cause for why the computer could join the domain, and then the trust was broken. So, the question remains: How do you detect a blocked port?

Nature of blocked ports
Port blocking is a somewhat secret event to tracing, but there are some very easy methods to determine if this is happening. Let's take these scenarios:

  • Scenario 1 - Port 3389: RDP enabled but blocked through the Windows Firewall
  • Scenario 2 - Port 3390 - nonexistent port
  • Scenario 3 - Port 3389: RDP enabled and allowed through the Windows Firewall

Some terms to know:
SrcPort: This is a randomized port between 49152 and 65535 which is used for a simple purpose, to track the transaction itself.
DestPort: This is the well known port that the traffic is being transmitted on.
Syn and SynRetransmit: This is the sending system's attempt to open a connection or re-open a connection (TCP only)
Ack: This is the acknowledgement from the receiving system that the packet was received. (TCP only)
TCP and UDP: The main difference between TCP and UDP is that TCP is connection oriented.
So with TCP, when a packet (or in some cases several) is being sent, it wants to know it's been received. It's very similar to a conversation where someone stops at points and says "Did you get me on this?" Or, when you call someone on the phone, you wait for a "hello" on the other end before proceeding.

A TCP conversation consists of 3 parts:
SYN: Initiates or synchronizes a connection
FIN: Terminates (finalizes) gracefully a connection
ACK: The acknowledgement of the received data.

So, how does this conversation work? Well, here is how a TCP connection is established in more human terms:
Sender: Opens the conversation by saying Hello to the receiver and waits for a response.
Receiver: Receives the sender's message and sends an acknowledgement back, waiting for the sender's response.
Sender: Receives the acknowledgement and sends another acknowledgment.
We now have a conversation started.

If we fail to receive that acknowledgement, the SynRetransmit kicks in, which is a more "did you hear me?" question.

or....
Me: Hello
You: Hello
Me: How's it going?
We now have a conversation started.

You can tell the TCP method takes a lot more overhead and wouldn't be practical in every case.

UDP on the other hand is not connection oriented. When a packet is sent, it's gone, and does not seek an acknowledgement. So, to the phone conversation above, UDP is like a robocall that may be speaking to a live ring and not caring if the broadcast is being received. This method produces far less overhead.

Practical Use: Heartbeats
So what about a practical use case, a heartbeat. We'll use Windows clustering as an example, where a UDP packet is sent over port 3343. The default threshold is 5 heartbeats over 1 second each, miss 5 heartbeats and the alarms sound (it's configurable, perhaps another blog).

A UDP packet is sent, and no acknowledgement is asked for. But wait, don't we need an acknowledgement to know the cluster nodes are alive and well, and wouldn't this be a job for TCP? Actually, no. Keep in mind that TCP incurs a lot more overhead and we only need to make sure that the cluster is alive and functioning. We send that 1 UDP packet and within the next 4 seconds (1 per packet), expect a packet back. This is not an acknowledgement, but more the hallway conversation between two co-workers with nothing more than a "Morning", "Morning" and they never bother to slow down.

Hope this was a good overview of the players involved in the network trace we will be doing in Part 2: the trace.

— Easy link to my blog: https://aka.ms/leesteve —
If you like my blogs, please share it on social media and/or leave a comment.