Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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

share|improve this question
    
May we enquire as to which country? –  Kev Jul 25 '12 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 '12 at 10:45
    
Is the capture taken from your machine trying to establish the connection? –  the-wabbit Jul 25 '12 at 11:30
    
Yes. I execute tcpdump -w gmail.pcap and then telnet gmail.com 443. –  Mohammad Jul 25 '12 at 11:53
    
telnet won't work, you need to see my answer below :-) –  The Unix Janitor Jul 25 '12 at 11:56

2 Answers 2

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.

share|improve this answer
    
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 '12 at 12:08
4  
thanks for the vote down guys...!!!!! –  The Unix Janitor Jul 25 '12 at 13:26
    
thanks for the +2 ...that cheered me up somewhat!!!! –  The Unix Janitor Jul 27 '12 at 13:56

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?

share|improve this answer
    
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 '12 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 '12 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 '12 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 '12 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 '12 at 11:44

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.