Why can I not access imgur.com and gravatar.com from Ubuntu but can do so from Windows?
I have this strange problem, I am unable to access imgur.com from Ubuntu !
I have checked the /etc/hosts file, there seems to no entry related to imgur. I can access it from Windows(same connection).
I cannot ping it or traceroute it, I cannot even ping the IP of imgur. I have cleared iptables too, what could be the cause ?
i cannot access gravatar.com too !! I just noticed that sorry.
Running host imgur.com (the same output with google's dns servers)
gowtham@gowtham-hacktohell:~$ host imgur.com
imgur.com has address 23.23.110.58
imgur.com has address 23.23.110.81
imgur.com has address 54.243.128.92
imgur.com mail is handled by 5 alt1.aspmx.l.google.com.
imgur.com mail is handled by 1 aspmx.l.google.com.
imgur.com mail is handled by 10 aspmx2.googlemail.com.
imgur.com mail is handled by 5 alt2.aspmx.l.google.com.
imgur.com mail is handled by 10 aspmx3.googlemail.com.
Running tcptraceroute
gowtham@gowtham-hacktohell:~$ tcptraceroute imgur.com
Selected device ppp0, address 117.199.141.54, port 44995 for outgoing packets
Tracing the path to imgur.com (54.243.128.92) on TCP port 80 (http), 30 hops max
1 117.199.128.1 17.534 ms 17.764 ms 17.896 ms
2 218.248.171.102 93.272 ms 26.393 ms 109.985 ms
3 115.114.130.49.STATIC-Chennai.vsnl.net.in (115.114.130.49) 49.442 ms 47.180 ms 46.981 ms
4 * * *
5 ix-0-100.tcore2.MLV-Mumbai.as6453.net (180.87.39.25) 70.085 ms 69.712 ms 70.361 ms
6 if-2-2.tcore1.MLV-Mumbai.as6453.net (180.87.38.1) 186.862 ms 186.434 ms 185.515 ms
7 if-9-5.tcore1.WYN-Marseille.as6453.net (80.231.217.17) 181.965 ms 182.963 ms 184.682 ms
8 if-8-1600.tcore1.PYE-Paris.as6453.net (80.231.217.6) 186.152 ms 184.483 ms 182.950 ms
9 if-12-2.tcore1.PVU-Paris.as6453.net (80.231.154.70) 191.271 ms 189.655 ms 188.606 ms
10 if-3-2.tcore1.FR0-Frankfurt.as6453.net (80.231.153.54) 187.245 ms 186.013 ms 193.808 ms
11 xe-0-1-0-6.r02.frnkge03.de.bb.gin.ntt.net (129.250.9.57) 288.412 ms 281.124 ms 281.011 ms
12 ae-2.r20.frnkge04.de.bb.gin.ntt.net (129.250.5.217) 352.432 ms 357.071 ms 357.256 ms
13 ae-1.r21.asbnva02.us.bb.gin.ntt.net (129.250.3.20) 391.405 ms 394.961 ms 391.812 ms
14 ae-2.r00.asbnva02.us.bb.gin.ntt.net (129.250.3.114) 378.128 ms 381.786 ms 385.697 ms
15 ae-4.amazon.asbnva02.us.bb.gin.ntt.net (168.143.232.50) 370.938 ms 353.306 ms 351.793 ms
16 72.21.220.55 361.004 ms * 364.525 ms
17 205.251.245.55 368.187 ms 380.907 ms 375.333 ms
18 * * *
19 * * *
20 * * *
I dial the connection using PPoE.
Capturing the stream through Wireshark, I see this
(source: akamaihd.net)
Running curl
gowtham@gowtham-hacktohell:~$ curl -I http://imgur.com
HTTP/1.1 200 OK
Server: nginx
Date: Fri, 11 Jan 2013 12:24:01 GMT
Content-Type: text/html
Connection: keep-alive
Cache-Control: max-age=5, s-maxage=5, must-revalidate
X-Cached: EXPIRED
And telnetting,
gowtham@gowtham-hacktohell:~$ telnet imgur.com 80
Trying 23.23.110.58...
Connected to imgur.com.
Escape character is '^]'.
HEAD / HTTP/1.0
HTTP/1.1 200 OK
Server: nginx
Date: Fri, 11 Jan 2013 12:25:11 GMT
Content-Type: text/html
Connection: close
Cache-Control: max-age=5, s-maxage=5, must-revalidate
X-Cached: HIT
Connection closed by foreign host.
This may be a MTU path discovery issue. This can lead to certain websites working incorrectly even though all others work fine. It will appear as a time out rather than connection refused. It will only show up with reasonably large transfers like whole webpages - telnet will probably not send any packets which need to be fragmented. It can affect outgoing ssh too.
The fix is to lower the MTU on your network device so that packets above a certain size are always fragmented. See for example:
http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.cookbook.mtu-discovery.html
In detail what happens is that when you send data over the internet it is split up into packets. The maximum size for these packets anywhere on the internet is 1460 bytes not including headers. If you send a message large than that it must be split up, or fragmented.
Now, if your message goes over certain types of internet links it must be encapsulated in another protocol. That means that the packet including headers will get wrapped inside another packet. That obviously increases the size of the packet, so if your packet is already maximum size it must be split up again. However, because this can be exploited to perform DDoS attacks, many routers won't automatically fragment packets that they didn't create. Therefore your maximum size packets won't cross these routers.
In order to avoid this problem MTU path discovery was invented. If a packet is too big for a router it will send back a message saying to send smaller packets. However, it turns out this could be exploited too, and so many routers won't do that either.
So the way to overcome this problem is to always send packets slightly smaller than the absolute maximum. That's what the MTU setting is for. The idea is to set it just small enough that any extra overhead doesn't put you over the limit. Of course you won't know how small that is so you have to find the optimal value (biggest value that still works) by experimentation.