While working with server builds and configurations, one is frequently faced with a scenario where the system (as a client), needs to connect to a server at the other end and the process doesn’t work.  If one’s lucky then an intelligent message is returned by the interface, hinting about the problem but more often than not, the message says something on the lines of: “I failed for some unknown reason.  Please work out for yourself what went wrong.”

I’ve found that in a lot of cases, it’s due to some firewall blocking a particular kind of conversation.  Companies are quite security conscious these days (a good thing!) so there usually are multiple layers of protection in place, making such communication impossible unless it is specifically allowed at all layers.  So, is there an easy method of finding out if some firewall is in the way of you successfully making your connection?  Fortunately, I’ve been using a simple “out-of-the-box” technique for quite a few years now which has saved me loads of times over that period.  As I quite frequently find people who are still unaware of this easy technique, I thought I should share it here so that people can benefit from it.

Now, before I start, I am assuming that people will use this on Windows and *nix systems and we’re talking some TCP protocol here.  With that assumption in place, if I need to work out if a firewall is blocking my communication, I open a command-prompt (assuming a Windows system first) and type:

netstat -ano 1 | findstr -i SYN_SENT

where 1 is the interval in seconds, meaning it will keep refreshing the results every second. Hit Ctrl+C to exit.

Initially, it shouldn’t return anything.  The next step is to run the process that was being attempted previously and simultaneously, run the command again.  If a firewall is blocking communication, an output will be returned, showing SYN_SENT status for the client:port/server:port pair (also with the ProcessID to help verify we’re looking at the right process).  Once this happens, you can see which protocol(s) is/are being blocked and then it could be passed on to the network administrator to decide upon and open if appropriate.  The equivalent command I use on *nix systems is:

netstat -anc | grep -i SYN_SENT

Explanation: This technique relies on the fact that every TCP connection starts with a three-way handshake.  The client sends a SYN packet and waits for an ACK packet from the server.  While it waits, the connection status is set to SYN_SENT.  If there is a firewall blocking the connection, the server won’t ever receive the SYN and therefore, will never reply.  This means, for the duration of the process i.e. until timeout, the client’s connection will remain in SYN_SENT status.  This is basically what we’re looking for when using the commands mentioned above.  As you can see, you have to be quick to run the command while the process is being run as SYN_SENT status disappears very quickly, once the connection attempt times out.

Bonus Tip: As all we’re doing above is running a command, piping the output into a string filter and searching for a particular string, the same technique can be used in various other scenarios where a lot of output is returned and you need to filter the output, to look for a particular string e.g. a target server or status.  For example, running:

dcdiag /v | findstr -i “test”

is much more efficient in displaying success and failure results than without the filter.

Hope this helps!