I am suspicious that my country's government is destroying the received ACK packet on TCP connections, somehow.

When I try to establish a TCP connection to an outside host on ports other than 80 the TCP handshake will not be successful. I captured the pcap file (gmail.pcap : http://www.slingfile.com/file/aWXGLLFPwb ) and I found out that my computer will receive the ACK after sending TCP SYN but instead of replying with a SYN ACK it will send an RST.

I checked the ACK packet from outside host, but it seems completely legit. The sequence number and all the flags that I am aware of, are correct. Could anyone tell me why my computer (a linux machine) will send the RST packet?

pcap screenshot

  • May we enquire as to which country?
    – Kev
    Jul 25, 2012 at 10:23
  • I deliberately did not mention it. But now that you ask, I can't think of a reason why not to tell. This is one of my day-to-day problems in Iran.
    – Mohammad
    Jul 25, 2012 at 10:45
  • Is the capture taken from your machine trying to establish the connection?
    – the-wabbit
    Jul 25, 2012 at 11:30
  • Yes. I execute tcpdump -w gmail.pcap and then telnet gmail.com 443.
    – Mohammad
    Jul 25, 2012 at 11:53
  • telnet won't work, you need to see my answer below :-) Jul 25, 2012 at 11:56

2 Answers 2


Although the Iranian gouvernment is rumored to break HTTPS from time to time, from the data you've provided it merely looks like the responding SYN,ACK packet from is arriving at your host, but never making it to your TCP stack. The stack retries sending SYNs after a second, two seconds, four seconds and eight seconds respectivly - but apparently never is seeing a response.

The incoming SYN,ACK seems to be filtered - you don't have an iptables rule for tcp traffic in your INPUT chain which has a REJECT --reject-with tcp-reset target by any chance?

  • No, my iptables doesn't have any rules at all and on another note I have to say I can establish TCP connection successfully to any host inside iran or even a couple of foreign web sites (only kernel.org actually!)
    – Mohammad
    Jul 25, 2012 at 12:15
  • 1
    My guess is that government is changing the second packet (SYN/ACK) so the packet is not valid and therefore it is never making it to the TCP stack.
    – Mohammad
    Jul 25, 2012 at 12:19
  • 1
    @Mohammad The packet is valid. Even if it were not, the stack would not do both: respond with an RST and proceed as if it has not been received. Something is catching it on the way to the stack. I suggest booting a known-clean install (e.g. a live Linux CD) and re-running the tests
    – the-wabbit
    Jul 25, 2012 at 12:47
  • Thank you. I couldn't find any problem with the ACK packet myself too. But the thing is that this problem happens every day (from 4 days ago) at morning in my workplace! Every body (about 50 person) have exactly the same problem and I still wonder why? I don't have the same problem at home but I hear from my friends that Internet has serious problems these days.
    – Mohammad
    Jul 25, 2012 at 12:56
  • 3
    @Mohammad check for malware then. Running a known-clean install as suggested above is an easy and significant test for this case.
    – the-wabbit
    Jul 26, 2012 at 11:44

From the cmd line:

openssl s_client -connect serveryourtryingtocontact.com:443

This should verify if you can SSL connect to the remote host. Perhaps make a Wireshark of this traffic.

If you don't have openssl , then you can apt-get install openssl.

We must determine where the RST is being generated. Does it happen to all SSL sites? Do you have a direct connection to your NAT-gateway? Are you using a proxy?

Using this method rules out any problem with your SSL stack.

  • The problem is not SSL. It is TCP. The TCP connnection will not establish at the first place, so SSL will not even begin to send its header. it is not only 443 port number e.g I can't even start a normal http connection to a server on port 8000 and your openssl command will result in "connect: Connection timed out"
    – Mohammad
    Jul 25, 2012 at 12:08

You must log in to answer this question.

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