StevensNet.com

...Because someone's gotta tell the story...

Blogs

To return to the main Blog List, click Full Blog Listing.

Tags

Firewall
Remote Desktop
SMB
Technical
Windows

Detecting port availability and blockage: Part 1, The Players

Thursday, August 31, 2017 in Technical Articles (Views: 340)
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

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.

 

Related Blogs You May Be Interested In:


To leave a comment, please log in and/or register.