SYN-ful Experiment
by Gr@ve_Rose
SYN/SYN-ACK/ACK is the basic and initial part of a TCP conversation which happens every time you make a connection from one host to another using the TCP protocol.
If you've been networking for a long time, this is always at the forefront of your mind when troubleshooting. If you're new to networking, here's a quick breakdown:
Let's say you want to initiate an HTTP connection to www.2600.com from your browser.
Your computer will send a SYN packet to the server which, in basic terms, is just a "Hey, I want to talk to you."
The server then sends back a SYN-ACK packet which is, "Hi. Yeah, let's talk."
Lastly, the client will send an ACK packet after which data transfer begins. This basic process is also known as the "three-way handshake" or "TCP handshake."
There is quite a lot of information within these packets like sequence numbers and other such items but I won't go into them here. We're just interested in the handshake for the purpose of this article.
Before I get to the details and code, I feel it would be wise to share the "Why?" portion of this equation:
I work for a large networking/security company on the reactive support side of things which means that I get a lot of interesting scenarios where someone's firewall isn't working properly or they're having troubles with a specific feature of their firewall. One day, a coworker of mine was working on a case where the client's firewall would turn a SYN packet into an ACK packet for no apparent reason. Weird, eh?
After doing some more in-depth research, we found out that the client was using a specific device behind the firewall which had a limited number of source ports to use and that when it attempted to create a new connection, the firewall would see the packet come from the same source port before the TCP end timeout was reached and thought it was part of the connection.
As we explained this to the client, they wanted proof that the firewall was not the problem (a fair request) and that it was their device.
So we set out to reproduce the issue.
The biggest hurdle we came across is that all the programs that we could find for generating a TCP handshake would close the connection with a FIN packet immediately after running. We needed it open, not closed, so we could test our hypothesis. That is how this came to be...
The Perl code itself is very simple. It uses IO::Socket::INET to open a TCP connection from one host to another. Yes, it sounds just like Telnet.
However, with this code you can specify the source port of the client. This will ensure that when you are troubleshooting a possible SYN issue, you can use the same source port as an already established connection. You can also use this to open an initial connection and use it as a "door stopper" so you can further test the issue at hand.
Code: grass.pl Gr@ve_Rose's Atomically Small SYN (GRASS) v0.5