Google services seems to be down if you’re accessing them via an IPv6 tunnel provider [Update 2]

November 8, 2014

For one of my Internet connections I use Hurricane Electric as IPv6 tunnel broker and the Google services (also Youtube) seems to be not accessable over it. I searched through the Internet and it seems that this is a more wide spread problem also with other tunnel brokers and other users. It is also interesting that following works.

first the dns request:
$ host www.google.com
www.google.com has address 188.21.9.57
www.google.com has address 188.21.9.56
www.google.com has address 188.21.9.59
www.google.com has address 188.21.9.53
www.google.com has address 188.21.9.52
www.google.com has address 188.21.9.55
www.google.com has address 188.21.9.54
www.google.com has address 188.21.9.58
www.google.com has IPv6 address 2a00:1450:4014:80b::1013

the ping to the IPv6 address works too:
$ ping6 2a00:1450:4014:80b::1013
PING 2a00:1450:4014:80b::1013(2a00:1450:4014:80b::1013) 56 data bytes
64 bytes from 2a00:1450:4014:80b::1013: icmp_seq=1 ttl=57 time=82.5 ms
64 bytes from 2a00:1450:4014:80b::1013: icmp_seq=2 ttl=57 time=93.3 ms
64 bytes from 2a00:1450:4014:80b::1013: icmp_seq=3 ttl=57 time=68.3 ms
64 bytes from 2a00:1450:4014:80b::1013: icmp_seq=4 ttl=57 time=75.5 ms

but a HTTP request runs into a timeout:
$ wget www.google.com
--2014-11-08 11:42:29-- http://www.google.com/
Resolving www.google.com (www.google.com)... 2a00:1450:4014:80b::1013, 188.21.9.56, 188.21.9.59, ...
Connecting to www.google.com (www.google.com)|2a00:1450:4014:80b::1013|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://www.google.de/?gfe_rd=cr&ei=lfNdVKbtEumk8wfgv4DgDg [following]
--2014-11-08 11:42:29-- http://www.google.de/?gfe_rd=cr&ei=lfNdVKbtEumk8wfgv4DgDg
Resolving www.google.de (www.google.de)... 2a00:1450:4014:80b::1017, 188.21.9.52, 188.21.9.56, ...
Connecting to www.google.de (www.google.de)|2a00:1450:4014:80b::1017|:80... connected.
HTTP request sent, awaiting response...

after the initial redirect … so small packets seem to go through but big not .. that looks like an MTU problem.

ps: yes
$ ping6 2a00:1450:4014:80b::1017
PING 2a00:1450:4014:80b::1017(2a00:1450:4014:80b::1017) 56 data bytes
64 bytes from 2a00:1450:4014:80b::1017: icmp_seq=1 ttl=57 time=100 ms
64 bytes from 2a00:1450:4014:80b::1017: icmp_seq=2 ttl=57 time=63.6 ms

works too. 😉

Update:

Take also a look at following links:

  • https://www.sixxs.net/forum/?msg=general-12626989
  • https://forums.he.net/index.php?topic=3281.0

Update 2:

The PMTUD seems to be not working .. Details on PMTUD und MTU and MSS can be found here.  Workaround seems to be to set the MTU size to 1480 – it works for me and in IPv6 that’s MSS 1420 (60byte instead of 40 in IPv4). On a Mikrotik RouterOs it works like this:

/ipv6 firewall mangle add action=change-mss chain=forward new-mss=1420 protocol=tcp tcp-flags=syn tcp-mss=!0-1420 comment="max MTU size in Tunnel 1480 .. workaround for google bug"

On Linux it is similar with iptables:
ip6tables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1420

No Comments yet »

RSS feed for comments on this post. TrackBack URI

Leave a comment

XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Powered by WordPress
Entries and comments feeds. Valid XHTML and CSS. 67 queries. 0.178 seconds.