Is my TCP connections sabotaged by my country's government?

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?

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.

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 173.194.32.22 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?