Is My Traffic Being Blocked? (or Using Wireshark to Unanswered SYN Packets)

One of the most frustrating things in network troubleshooting can be finding out if traffic is being blocked. Blocked traffic can keep applications or a services from running correctly. A lot of applications will throw unhelpful or vague error messages.

Until relatively recently the average network was a pretty open and trusting place. Most computers were allowed to receive and send traffic on any port they pleased, any protocol was allowed to use any port with no explanation required.

But with ideas like network segmentation becoming more prevalent, and tools like AWS security groups essentially wrapping each server in a tiny firewall, those ideas are changing. It's much more common for firewall and security admins to white list traffic and only allow the ports and services explicitly asked for.

My goal with this post is to get you focus a packet capture to find this blocked traffic, which can be very helpful for your network or firewall admins by relieving headaches, reducing stress, and getting you up and running faster. I'm assuming you're somewhat familiar with TCP and Wireshark.

This brings us to a really helpful aspect of the TCP 3 way handshake: it's relatively easy to find TCP conversations that never leave the initial state, which usually means that traffic is being blocked.

Let's look at a healthy example to get some context.

I marked off the TCP flags because that's the piece we're interested in. This is an example of my laptop reaching out to a web server on port 443. The three packets follow the standard TCP handshake

1. My laptop sends a SYN ("Hi, I'm a client and I'd like to connect.")
2. The server sends a SYN,ACK ("Hi, I'm a server and I'd like to connect to.")
3. My laptop sends an ACK ("Sounds good. Let's be friends!")

NOTE: The parentheticals are paraphrased for comedic effect.

How does this help us find blocked traffic? Well we can use a Wireshark analysis to look for conversations the client is trying to start that never get answered.

When a typical application sends a SYN packet out, but never receives a SYN,ACK back from the server it will retry the SYN packet several times, hoping to get a connection. Because the application is trying the same thing over and over again we can use a wireshark analysis that finds retransmitted packets:

tcp.analysis.retransmission

I'll use start a wireshark packet capture on my wireless adapter and use a powershell command to initiate traffic to a port on the internet I know won't respond, say 4433 on google.com:

Test-NetConnection -Port 4433 -computername google.com

And then apply a filter in wireshark to look for retransmitted packets to this port, and they jump right out!

If this were a real application I was trying to fix, and not just a toy example I'd be able to go to my network admin and tell them that I see traffic leaving my server outbound for the IP and port in the capture.

In this toy example I was able to be very specific, but in real life you might not know port your application is trying to communicate on. In this scenarios you might wind up capturing a lot of traffic pretty fast. For example when I started this paragraph I turned on a packet capture with no filters and in the time it took me to type this I caught around 500 packets just from background activity on my laptop!

That can quickly turn into a lot of traffic to sort through, so we can add a Wireshark filter to look only for SYN retransmits.

Test-NetConnection -Port 4433 -computername google.com

In English this is saying, "Show me the packets that are being retransmitted AND are the beginning of a TCP conversation."

And you can see this filter let me find my 4433 traffic pretty easily (and something on port 8013 my laptop sincerely wants to talk to).

Happy packet capturing!