Thanks clayjar
and svideo
for providing packet captures.
Here are my observations:
1. After google recieves an SYN from clayjar
's computer, it replies with SYN/ACK
17:24:50.305541 IP (tos 0x20, ttl 53, id 57627, offset 0, flags [none], proto TCP (6), length 60) py-in-f147.google.com.http > 192.168.12.3.36519: S, cksum 0x1a42 (correct), 1211513156:1211513156(0) ack 4243223793 win 5672 <mss 1430,sackOK,timestamp
28289791 2587334990,nop,wscale 0>
Pay attention to the following:
-- time to live
(ttl 53) (it means google is 11 hops away, but we are not concerned about the exact number).
-- the
tcp timestamp (28289791) -- the tcp window size
(win 5672). Note that OS defaults differ on this value (check dslreports.com speed tweaks faqs).
2. After the computer completes the handshake by sending an ACK and start the connection(PSH), here come the mysterious RSTs:
17:24:50.328010 IP (tos 0x0, ttl 51, id 57631, offset 0, flags [DF], proto TCP (6), length 52) py-in-f147.google.com.http > 192.168.12.3.36519: R, cksum 0x255e (correct), 1211513157:1211513157(0) win 10240 <nop,nop,timestamp 28290791 0>
17:24:50.328113 IP (tos 0x0, ttl 51, id 57632, offset 0, flags [DF], proto TCP (6), length 52) py-in-f147.google.com.http > 192.168.12.3.36519: R, cksum 0xf486 (correct), 1211525660:1211525660(0) win 10240 <nop,nop,timestamp 28290791 0>
Here we have a
ttl 51 which indicates that these packet are not from the original source (Google). Another clue is the tcp window size (win 10240), which can not be that high without scaling after a connection is established.
It is clear that this a different host sitting in the middle. Also note that the 2 RST packets were sent 0.0017 seconds in between! This is very unusual.
And
tcp timestamp 28290791, although optional, but decreased!?
3.The computer upon recieving the RST, replies with an RST and closes its side of the connection:
17:24:50.332401 IP (tos 0x20, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 192.168.12.3.36519 > py-in-
f147.google.com.http: R, cksum 0xf8e4 (correct), 4243224049:4243224049(0) win 0
4. And finally, ffw, Google upon recieving RSTs from the host in the middle, closes its side of the connection. Note here we confirm it is google:
(ttl 53), a consistent
tcp timestamp (28289791), and a low
(win 6432). No need to go into window scaling discussion.
17:24:50.381396 IP (tos 0x20, ttl 53, id 57629, offset 0, flags [none], proto TCP (6), length 52) py-in-f147.google.com.http > 192.168.12.3.36519: R, cksum 0x44c9 (correct), 1:1(0) ack 257 win 6432 <nop,nop,timestamp 28289799 2587335018>
Conclusion: there is something out there resetting tcp connection to that ip address.
Now, the question is: how come it is possible to use the ip address directly to connect to Google?
My answer: most likely a DNS issue. It could be that at certain times of the day, Google.com DNS entries change to ip addresses that "the host in the middle" above does not like. Keep in mind that, as mentioned in this thread, that Google's DNS entries have very short TTLs:
C:\>nslookup
> set debug
> www.google.com
Server: UnKnown
Address: 192.168.10.1
------------
Got answer:
HEADER:
opcode = QUERY, id = 6, rcode = NXDOMAIN
header flags: response, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 0, additional = 0
QUESTIONS:
www.google.com.lan, type = A, class = IN
------------
------------
Got answer:
HEADER:
opcode = QUERY, id = 7, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 3, authority records = 0, additional = 0
QUESTIONS:
www.google.com, type = A, class = IN
ANSWERS:
-> www.google.com
canonical name = google.navigation.opendns.com
ttl = 8 (8 secs)
-> google.navigation.opendns.com
internet address = 208.67.216.231
ttl = 8 (8 secs)
-> google.navigation.opendns.com
internet address = 208.67.216.230
ttl = 8 (8 secs)
------------
Non-authoritative answer:
Name: google.navigation.opendns.com
Addresses: 208.67.216.231, 208.67.216.230
Aliases: www.google.com
>