Here, you will learn some indicators and what you can see when you use Wireshark for debugging TCP connectivity problems. Usually, these problems result in you 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 don't get any output, follow these steps:

1. Verify that the server and applications are running.
2. Verify that your client is running, you have an IP address configured (manually or by DHCP), and that you are connected to the network.
3. Ping the server and verify that you have connectivity to it.
4. In the capture file, look for one of the following patterns:
   • Triple SYN messages with no response
   • SYN messages with a reset (RST) response

In both cases, it could 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 with 81.218.31.171.

In the next illustration, 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 watched 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 in to the system. In the following screenshot, we can see that we open a connection to the IP address 135.82.12.1. We can see that a TCP connection is opened to the HTTP server, and at first, it looks as if there are no connectivity problems:

The problems arise when we filter all traffic to IP address 135.82.12.1, that is, the cameras server.

Here, we can see that when we try to connect to TCP port 6036, we get an RST/ACK response, which can be for the following reasons:

• A firewall that blocks port 6036 (that was the case here)
• When the port address translation (PAT) is configured and we translate only port 80 and not 6036
• The authentication of the username and password were done on TCP port 6036, the firewall allowed only port 80, 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 to see whether all TCP/UDP ports are forwarded throughout the network and whether you have any ports that you don't know about.