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.

For a number of weeks HE tunnel users have being reporting packet loss, it's thought this might be due to abuse.

Interesting, do you know if this is limited to a specific endpoint?

I was wondering if it was only me... do you have any links about those complaints?

I can confirm requesting a routed /48 and configuring that on the router fixes the issue

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