14

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

pQd
  • 29,561
  • 5
  • 64
  • 106
Mohammad
  • 149
  • 3
  • 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
  • can you add result of iptables -nL ; iptables -t nat -nL from your machine? also can you try to disable tcp checksum offloading by running ethtool -K eth0 rx off tx off sg off tso off and repeat your tests, add new dump? – pQd Jul 25 '12 at 12:10
  • @pQd: I executed the iptables and all the chains are empty. But the ethtool says "Cannot set device rx csum settings: Operation not supported" – Mohammad Jul 25 '12 at 13:05
  • This problem occurs at my workplace. I am going home now! So I might answer the comments with delay, if any... Tomorrow is a holiday but fortunately I have ssh access to my workplace from home (if the internet is not broken there!) – Mohammad Jul 25 '12 at 13:10
  • my wireshark reports incorrect tcp checksums - this can be caused by the tcp offloading handled by your network card, that's why i ask you to temporarily disable it and get a new dump. – pQd Jul 25 '12 at 13:34
  • @pQd: You are right. Apparently my network adapter doesn't support rx offloading off. but I turned off every thing else with ethtool -K and here is the result: http://www.uploadmb.com/dw.php?id=1343450959 . Exactly the same. the strange thing is the sending packets from my side have wrong tcp checksum not the received ones. I tried it on other computers in our network but the results didn't change. could it be a miss configuration in our network? – Mohammad Jul 28 '12 at 04:53
  • Nah! We are on the wrong track. this is the pcap file I captured from connecting to kernel.org: http://www.uploadmb.com/dw.php?id=1343452091 . The tcp checksum is incorrect here, too but the connection doesn't fail. kernel.org is the only non-Iranian website that I can make a tcp connection on port 443 that I am aware of. – Mohammad Jul 28 '12 at 05:12
  • The TCP checksum on transmitted packets is commonly set to zero - your NIC does the calculation after Wireshark has captured the packet, no need to worry about that. Your second capture shows a pretty usual handshake, although packet #3 (the ACK from your side) is apparently lost in transit so the SYN,ACK gets resent by kernel.org. – the-wabbit Jul 31 '12 at 08:34
  • can you update us how did it end? – pQd Aug 12 '12 at 18:48

2 Answers2

6

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.

johnny
  • 137
  • 1
  • 5
The Unix Janitor
  • 2,388
  • 14
  • 13
  • 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
5

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?

the-wabbit
  • 40,319
  • 13
  • 105
  • 169
  • 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