When two TCP processes wish to communicate, they open the connection, send the data, and then close the connection. This happens when you open a browser to the Internet, connect from your mail client to the mail server, or connect with Telnet to your router or any other application that works over TCP.
When TCP opens the connection, it sends a request for open connection from the source port to destination port.
Some problems can occur during the establishment or closing of the application. Using Wireshark to locate and solve these problems is the goal of this recipe.
If you experience one of the following problems, use Wireshark in order to find out what is the reason for it.
These problems can be of many types. Of these:
- You try to run an application and it does not work. You try to browse the Internet and you don't get any response.
- You try to use your mail but you don't have a connection to the mail server.
- Problems can be due to simple reasons, such as the server being down, the application is not running on the server, or the network is down somewhere on the way to the server.
- Problems can be also due to more complicated reasons, such as DNS problems, insufficient memory on the server that does not enable you to connect (due to high memory consumption by an application, for example), duplicate IPs, and many others.
In this recipe we focus on these GO/NO-GO problems that are usually quite easy to solve.
Here you will see some indicators and what you can see when you use Wireshark for debugging TCP connectivity problems. Usually these problems result in trying to run an application and getting no results.
When you try to run an application, for example, a database client, a mail client, watching cameras servers, and so on, and you don't get any output, follow these steps:
- Verify that the server and applications are running.
- Verify if your client is running, you have an IP address configured (manually or by DHCP), and you are connected to the network.
- Ping the server and verify you have connectivity to it.
Tip
In some cases, you will not have Ping to the server, but still have connectivity to the application. This can happen because a firewall is blocking the ICMP messages, so if you don't have Ping to a destination it doesn't necessarily mean that something is wrong. The firewall can be a dedicated device in the network or a windows (or Linux/UNIX) firewall installed on the end device.
- In the capture file, look for one of the following patterns:
- Triple SYN messages with no response (in the following screenshot)
- SYN messages with a reset (RST) response
In both cases it can be that a firewall is blocking the specific application or the application is not running.
In the following screenshot, we see a simple case in which we simply don't get access to web server 81.218.31.171 (packets 61, 62, and 63). It can be because it is not permitted by a firewall, or simply because there is a problem with the server. We can also see that we have a connection to another website (108.160.163.43, packets 65, 66, and 67), so the connection problem is only to 81.218.31.171.
In the next screenshot we see a slightly more complex case of the same situation. In this case, we've had a cameras server that the customer wanted to log in to and watch the cameras on a remote site. The camera's server had the IP address 135.82.12.1 and the problem was that the customer was able to get the main web page of the server with the login window, but couldn't log into the system. In the following screenshot, we can see that we open a connection to the IP address 135.82.12.1. We see that a TCP connection is opened to the HTTP server, and at first it looks like there are no connectivity problems:
The problems arise when we filter all traffic to the IP address 135.82.12.1, that is, the cameras server.
Here we see that when we try to connect to TCP port 6036, we get an RST/ACK response, which can be:
- A firewall that blocks port
6036(that was the case here) - When port address translation (PAT) is configured, and we translate only port
80and not6036 - The authentication of the username and password were done on TCP port
6036, the firewall allowed only port80, the authentication was blocked, and the application didn't work
To summarize, when you don't have connectivity to a server, check the server and the client if all TCP/UDP ports are forwarded throughout the network, and if you have any ports that you don't know about.
Tip
In some cases when you install new applications in your network, it is good to connect Wireshark on the client and the server, and check what is actually running between them. The software house will not always tell you what they are actually transferring over the network (sometimes this is because they are not aware of it!), and firewalls can block information that you are not aware of.
Starting a TCP connection, as seen in the next screenshot, happens in three steps:
- The TCP process on the client side sends an SYN packet. This is a packet with the SYN flag set to
1. In this packet the client:- Specifies its initial sequence number. This is the number of the first byte that the client sends to the server.
- Specifies its window size. This is the buffer the clients allocate to the process (the place in the client's RAM).
- Sets the options that will be used by it: MSS, Selective ACK, and so on.
- When the server receives the request to establish a connection, the server:
- Sends an SYN/ACK packet to the client, confirming the acceptance of the SYN request.
- Specifies the server's initial sequence number. This is the number of the first byte that the server sends to the client.
- Specifies the server's window size. This is the buffer size that the server allocates to the process (the place in the server's RAM).
- Responds to the options requested and sets the options on the server side.
- When receiving the server's SYN/ACK, the client:
- Sends an ACK packet to the server, confirming the acceptance of the SYN/ACK packet from the server.
- Specifies the client's window size. This is the buffer size that the client allocates to the process. Although this parameter was defined in the first packet (the SYN packet), the server will refer to this one since it is the latest window size received by the server.
In the options field of the TCP header, we have the following main options:
- Maximum Segment Size (MSS): This is the maximum size of the TCP datagram, that is, the number of bytes from the beginning of the TCP header to the end of the entire packet.
- Windows Size (WSopt): This factor is multiplied with the Window Size field in the TCP header to notify the receiver on a larger size buffer. Since the maximum window size in the header is 64 KB, a factor of 4 gives us 64 KB multiplied by 4, that is, a 256 KB window size.
- SACK: Selective ACK is an option that enables the two parties of a connection to acknowledge specific packets, so when a single packet is lost, only this packet will be sent again. Both parties of the connection have to agree on SACK in the connection establishment.
- Timestamps options (TSopt): This parameter was explained earlier in this chapter, and refers to measurement of the delay between client and the server.
By this stage, both sides:
- Agree to establish a connection
- Know the other side's initial sequence number
- Know the other side's window size
Some rules of thumb are as follows:
- In case an SYN packet is answered with RST, look for the firewall that blocks the port numbers.
- Triple SYN without any answer occurs either due to an application that didn't respond, or a firewall that blocks the request on a specific port.
- Always verify if you have Network Address Translation (NAT), port forwarding, and mechanisms that play with TCP or UDP ports. These mechanisms can interrupt with the standard operation of TCP.