www.google.com unreachable over he tunnel

[510sg]

curl -6 http://www.google.com hangs today. Normally that works.

[kcochran]

Seeing that working successfully via tunnels to all tunnel servers.

Any changes on your side, firewall rules, MTU, etc.?  What's the IP address it's trying to connect to, since Google operates clusters world-wide, it's possible you're resolving to one which our tests aren't.

[apophis04]

I have exactly the same problem. It suddenly stopped working without changing anything on my configuration. When doing

Code Select Expand

wget -6 https://www.google.com

Wireshark shows me "TCP Previous segment not captured". It tries to connect to 2a00:1450:4005:800::1014. The following works fine

Code Select Expand

ping6 -s 1424 2a00:1450:4005:800::1014

Using a ping package size of 1425 doesn't work.

I'm using Linux kernel 3.13 from Ubuntu 14.04 and configured the tunnel via /etc/network/interfaces as given by the example configurations without the "local" option.

The tunnel MTU is 1480 but i tried other MTUs and it didn't work either.

[aandaluz]

I'm experiencing similar issues since yesterday (tserv10.par1). Some sites work (www.bsc.es), others  (ipv6-test.com,https://www.youtube.com,https://www.google.com) don't. In fact, I cannot even reach hurricane electric forums (https://forums.he.net) or he.net unless I disable ipv6 in my network adapter, although every url is pingable


I can also confirm that
ping6 2a00:1450:4005:800::1014  hangs if  -s >1232

ping6 -s 1232 2a00:1450:4005:800::1014
PING6(1280=40+8+1232 bytes) 2001:470:1f13:130a:614d:7833:5c3b:6c18 --> 2a00:1450:4005:800::1014
1240 bytes from 2a00:1450:4005:800::1014, icmp_seq=0 hlim=53 time=49.470 ms
1240 bytes from 2a00:1450:4005:800::1014, icmp_seq=1 hlim=53 time=48.019 ms
^C
--- 2a00:1450:4005:800::1014 ping6 statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 48.019/48.745/49.470/0.725 ms


ping6 -s 1233 2a00:1450:4005:800::1014
PING6(1281=40+8+1233 bytes) 2001:470:1f13:130a:614d:7833:5c3b:6c18 --> 2a00:1450:4005:800::1014
<---------HANGS

[devicenull]

I can confirm I've started seeing the same issue (started on Friday).

I'm using the NYC tunnel endpoint.  My actual ISP is optimum/cablevision

The largest ping I can send is 1432 data bytes.  Anything higher gets no response.

Code Select Expand


$ ping6 www.google.com -n -s 1432
PING www.google.com(2607:f8b0:400d:c06::67) 1432 data bytes
72 bytes from 2607:f8b0:400d:c06::67: icmp_seq=1 ttl=55 (truncated)
72 bytes from 2607:f8b0:400d:c06::67: icmp_seq=2 ttl=55 (truncated)
^C
--- www.google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1292ms
rtt min/avg/max/mdev = 26.856/27.142/27.428/0.286 ms

$ ping6 www.google.com -n -s 1433
PING www.google.com(2607:f8b0:400d:c06::67) 1433 data bytes
^C
--- www.google.com ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1500ms


[gnarlymarley]

I also started seeing this on Friday.  I am using tserv3.fmt2.  No changes on my side to cause this.  As a part of research to the cause of the problem, I brought up a sixxs tunnel and a gogo6 tunnel.  Both of those appear to be having the same issue, so I believe this might not be tserv3.fmt2, but could be inside google somewhere.  The issue is that about three out of five links, include the safebrowsing links in firefox, seem to be "hanging".  I see a syn and very slow packet flow.  I wonder if google has a data center down as both google and youtube keep wanting to point to 2607:f8b0:4000::/44.  The catch is that I disabled IPv6 and it would also appear to be carrying over to IPv4.  I am going to do some traveling later today to see if it is duplicated elsewhere.  I am seeing some intermittent routing issues with 2001:470:0:31::2, however, I am fairly certain that is not related to this issue, so not posting in this thread.  I suspect the issue is a router deep inside the google/youtube network.

[digitalhype]

I don't think these issues are related to he.net.  My tunnel is via fmt2.  I observed some ssl errors to docs.google.com this morning.  Something about a tls version downgrade causing secure connection to fail.  I noticed some others reporting similar issues on an afmug forum post.    This afmug post indicates that person had native IPv6 connectivity.  Evidence seems to indicate this issue is either inside Google, or close to it.

https://www.mail-archive.com/af@afmug.com/msg10847.html

[terrapin]

athena:~ pcurtis$ ping6 -c 5 -s 1220 gmail.com
PING6(1268=40+8+1220 bytes) 2001:470:1f07:533:b523:acdb:6446:c638 --> 2607:f8b0:4006:80b::1016
1228 bytes from 2607:f8b0:4006:80b::1016, icmp_seq=0 hlim=58 time=7.862 ms
1228 bytes from 2607:f8b0:4006:80b::1016, icmp_seq=1 hlim=58 time=7.674 ms
1228 bytes from 2607:f8b0:4006:80b::1016, icmp_seq=2 hlim=58 time=10.072 ms
1228 bytes from 2607:f8b0:4006:80b::1016, icmp_seq=3 hlim=58 time=40.224 ms
1228 bytes from 2607:f8b0:4006:80b::1016, icmp_seq=4 hlim=58 time=10.128 ms

--- gmail.com ping6 statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 7.674/15.192/40.224/12.560 ms


athena:~ pcurtis$ ping6 -c 5 -s 1240 gmail.com
PING6(1288=40+8+1240 bytes) 2001:470:1f07:533:b523:acdb:6446:c638 --> 2607:f8b0:4006:808::1016
1248 bytes from 2607:f8b0:4006:808::1016, icmp_seq=0 hlim=58 time=9.960 ms

--- gmail.com ping6 statistics ---
5 packets transmitted, 1 packets received, 80.0% packet loss
round-trip min/avg/max/std-dev = 9.960/9.960/9.960/0.000 ms

[aandaluz]

it seems that other tunnel brokers have the same problem
https://www.sixxs.net/forum/?msg=general-13022233

[Tiksi]

Confirming the same problem here, connected to .tserv4.nyc4.

This happened friday night, then got a bit better on Saturday, and just started happening again a couple hours ago. Adjusted my MTU in the meantime, hopefully it'll be fixed soon.

[broquea]

Someone in #ipv6 has opened a ticket, as well as this is making it onto ipv6-ops again. Oh Google, Y U break it for sub-1500 mtu users?

[gnarlymarley]

not seen the post with gogo6 yet, but that maybe because they are in canada, so get a different IP than in the 2607:f8b0:4000::/40 range.  My DNS didn't move much.  Over over IPv4 dns, google tries to force me to 2607:f8b0:4000:/48.  Over Sixxs, google tries to force me to 2607:f8b0:4000:/48.  Over gogo6, google tries to force me to 2607:f8b0:4009:/48.  Over HE tunnel, google tries to force me to 2607:f8b0:4010:/48.  I have found that 74.125.239.0/24 and 74.125.25.0/24 work great.

Code Select Expand


Name:    youtube-ui.l.google.com
Addresses:  2607:f8b0:4000:80b::2000
          74.125.239.39
Aliases:  www.youtube.com

As further proof that this is not a tunnel specific issue, I forced my IP to be 2001:4860:4001:10::17 by creating the following dns zones and it works.

Code Select Expand


youtube.com.               300     IN      SOA     localhost. me.localhost. 2004020117 10800 3600 604800 86400
                172800  IN      NS      localhost.
                172800  IN      AAAA    2001:4860:4001:10::17
*               172800  IN      AAAA    2001:4860:4001:10::17


Code Select Expand


google.com.               300     IN      SOA     localhost. me.localhost. 2004020117 10800 3600 604800 86400
                172800  IN      NS      localhost.
                172800  IN      AAAA    2001:4860:4001:10::17
*               172800  IN      AAAA    2001:4860:4001:10::17


So, all issues still points to 2607:f8b0:4000::/40.  When pointing to 2001:4860::/32, no issues found.

[rlatorre]

Just want to add that I've had this problem since Friday as well. I use the Toronto tunnelbroker. Mostly google that seems broken, although google is embedded in so much of the web that it seemed like half the internet was dead. It also appeared some non-google hosts were unresponsive (ie. CDN addresses.)

[bartgrefte]

Here's another "me too" report. Since this weekend, anything Google related is intermittently unaccessible through IPv6 (HE Amsterdam endpoint here), no matter what type of connection. Ruled out DNS issue by entering the IPv6 address.

Seeing reports on several websites:
- Dutch IT forum gathering.tweakers.net
- http://forums.whirlpool.net.au/forum-replies.cfm?t=2360847
- http://www.dslreports.com/forum/r29799531-DSL-IPv6-Google-connection-hanging
- http://www.gossamer-threads.com/lists/nsp/ipv6/53248

The guess is that Google screwed up mtu / "icmpv6 packet too big" (again), although dropping the mtu from 1480 to 1280 didn't solve the problem here.

[aandaluz]

Lowering my ethernet adapter MTU to 1280 on OSX did the trick, and now I can reach google and youtube  over ipv6 again


. I hope google's team fixes this issue asap   :-[