Topology: Client ----- Intermediate Device ----- Server

Client: win7

Intermediate Device: unknown

Server: CentOS 5.8

The problem occurs when the client and server are trying to establish a SSL connection. It happens to one specific port, 2000. I haven't been able to replicate the problem with other port numbers.

I captured packets on both client and server. After the TCP handshake, from the client's perspective, it's not receiving ACKs for its previously sent packets so it kept re-sending them. On the server side, however, it did receive those packets and sent ACK packets.

The weird thing is, after the server sent those ACKs, it received a [RST, ACK] packet, from the intermediate device, for every packet it sent.

What could be the cause?

  • Are they on the same wire? (i.e: no other devices in between such as a firewall, router, ...)
    – ndrix
    Jun 26, 2012 at 8:41
  • @m1ke No they are not on the same wire. The server is located in an IDC, and the client is my own desktop using ADSL(or something similar) Jun 26, 2012 at 8:47
  • Do you see any of the TLS handshake (Client Hello at least)?
    – Bruno
    Jun 26, 2012 at 10:22

1 Answer 1


If this happens after the SSL connection has been negotiated, it is possible that the intermediate device considers encrypted traffic on port 2000 as a potential security threat (or in some way "unwanted") and makes two things:

  • intercepts the "ACK" sent by the server so they do not reach the client that will consider the server as not responding
  • sends a reset to the server so that it will not keep the connection open waiting for traffic that will never come from the client
  • It happens during the SSL negotiaion; however, maybe the intermediate device thinks even trying to start an SSL session is a threat. Seems I have no choice but switch to another port. Jun 26, 2012 at 9:02
  • You are correct: my statement has to be corrected into "If it happens after the TCP connection..."
    – marcoc
    Jun 26, 2012 at 9:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .