Seems that Google is blocking HE.net tunneled IPv6 /64 subnets, the one you get by default when you set up a tunnel. The linked tweet suggests, and testing this morning confirms, that it's the /64 subnets being blocked, and that if you have a routed /48, the /48 is fine.
Yeah I was getting worried there for a minute wondering when I'd start to see it, but I've got the /48 setup and can also confirm no issues yet on my end.
Indeed. I usually use the initial /64 for small sites, and that's it, but larger sites that I manage with the routed /48 I usually use the /64 for the DMZ just to make firewall rules simpler/cleaner. On those sites, where the /64 is the DMZ, I was able to confirm that the Google search homepage was giving a 403 Unauthorized from anything on the /64.
Just to be clear, even if you have a routed /48, the /64 still associated with the tunnel may still be blocked. For me, in all of the networks I manage, the /64 is blocked.
The prevailing guess is HE.net carved up a /48 or /32 for those initial /64s and Google is blocking whatever larger block they all come from. The routed /48s must be from a different block.
There was a suggestion that it was rDNS dependent, but on those sites with a routed /48 the SLAAC hosts on the /48 had no issues, and the hosts on the /64 that got 403'ed all had static rDNS that matched their FQDNs. Definitely not rDNS related.
Probably someone tried to use a tunnel for a DoS, to access from a sanctioned country, or some other trigger for automatic blocking. Google really shouldn't block all HE because of one or a few subnets doing this, but it's understandable.
For the last few weeks, a number of HE.net tunnel users have reported an abundance of CAPTCHA requests, like for every single search homepage visit, which would be consistent with your supposition.
Interesting workaround, although it's kind of so overkill to get a /48 prefix and have 5-10 IP addresses used inside it... and what happens when the abusers will also get a /48?
I have a /64 from HE via tserv9.chi1.ipv6.he.net (184.105.253.14) and from my dual stack LAN hosts behind pfsense via Stateless DHCP (not DHCPv6), I recently began having trouble searching via Google's search engine over IPv6. Including via Chrome browser's search bar and Firefox the same, also just a straight up search from site google.com and to verify, the same from ipv6.google.com. I get great speeds via Xfinity speed test (IPv6 & IPv4) over Spectrum Business Class rated at 300Mbps. I considered getting a /48 as recommended, but I wondered if plain old firewall rules for LAN might help. Rejecting all LAN IPv6 to an alias containing every Google search hostname and IPv6 address I could find. And it actually worked. Only the Google Search IPv6 addresses are blocked up high in the rules so Google falls back to the IPv4 search addresses, which I don't have to declare, it just falls back from IPv6 to IPv4 Google search pages and the multi-bar. Of course DDGo is always a preferable option for searching, but on Android devices Google Search is so integrated it's easier to live with Google. Such a simple solution and it works, so I'm not arguing. Every other Google app continues to run over IPv6 including Gmail,Drive, Docs, Youtube, etc. I am blocking IPv6 per:
google.com, www.google.com, ipv6.google.com, 2607:f8b0:4023:1004::64, 2607:f8b0:4023:1004::65, 2607:f8b0:4023:1004::71, 2607:f8b0:4023:1004::8b, 2607:f8b0:4006:81f::200e, 2001:4860:4860::8888, 2001:4860:4860::8844
11 comments
[ 2.7 ms ] story [ 32.3 ms ] threadJust to be clear, even if you have a routed /48, the /64 still associated with the tunnel may still be blocked. For me, in all of the networks I manage, the /64 is blocked.
The prevailing guess is HE.net carved up a /48 or /32 for those initial /64s and Google is blocking whatever larger block they all come from. The routed /48s must be from a different block.
There was a suggestion that it was rDNS dependent, but on those sites with a routed /48 the SLAAC hosts on the /48 had no issues, and the hosts on the /64 that got 403'ed all had static rDNS that matched their FQDNs. Definitely not rDNS related.