I'm being forced to confirm that I'm a human when I create a perform a new google search. I can stop this behavior by changing my IPv6 settings from Automatic to Link-Local. This setting change stops me from using IPv6 to connect to google, or anything else.
Is anyone else seeing this?
-- Chris
Yep, me too, in Denver.
I started seeing this same problem on 31 May 2023.
I get the "I am not a robot" and multiple captcha images to solve.
If I turn off ipv6 the problem goes away.
Looks like time to switch to bing search.
Seeing the same problem starting May 31st. DuckDuckGo is looking like a fine alternative.
I can add that when on native IPv6 from AT&T via my phone, Google is fine. Also, blocking outbound https to google's ip fixes things. I'll check from my house on Friday if this is still a problem then.
I removed IPv6 DNS resolution for Google's domains overnight to work around the issue. I enabled this morning and the problem persists. I think Google is pulling a Netflix and considering HE tunneled connections as a VPN.
It's odd though. Only search (google.com) seemed to be affected. mail and docs were fine. I switched back to my CenturyLink 6RD for now but the next time my IPv4 address changes, I'm going to be in hell since the IPv6 network will also change.
Same here. European server.
Quote from: gtjoseph on June 01, 2023, 03:42:04 PMIt's odd though. Only search (google.com) seemed to be affected. mail and docs were fine.
It's just first day or two, who knows, perhaps in another couple of days the rest of google services would be blocked as well. My guess is someone did use HE tunnel for some nefarious purposes, causing the issue for everyone.
Edit: still haven't been solved, but DuckDuckGo proves to be an excellent substitute.
I've contacted support, they said they already know about it and working with google to resolve. Here's to hoping it'll go away :)
June 8 - looks it's been resolved. Took a week or so lol
I had to avoid searching google over IPv6 for about a week but now things seem to be working. Are other people seeing this too or have I misdiagnosed things?
- Chris
The ipv6 searching is back to normal for me at this time.
So, it worked for a few days. Now we have a new issue. Anything going to www.google.com is giving me a "403 forbidden" error.
Same issue. 403 forbidden.
Confirm, Google now seems to block ipv6 queries to search from HE tunnelbroker ASN
Glad to see that i'am not alone with this issue. Same things - first captcha, then (few week later) 403 Forbidden... Quering only with ipv4 "solves" te issue.
+
403, Forbidden.
Prefix 2001:470:1f15:1cf::1/64
Russia
Having similar issues, sad to see a bunch of sites blocking ipv6 tunnels, my ISP is absolutely refusing to implement any form of ipv6 so using the HE tunnel is the only way for my network to get it.
well, I've gotten 403 as well. ipv4 search works, ipv6 through the tunnelbroker gets error 403 (forbidden). It literally happened within the last couple of hours or so. When recaptcha problem hit, tunnelbroker support said they are working on it with google, I guess everything fell through after all
I have 5 tunnels and all of them are getting the same "Your client does not have permission to get URL / " from Google Search (https://www.google.com/).
I was very concerned, I was getting the captcha 2 weeks ago, and then last week it stopped. Now no one in our business locations or home is able to do Google search unless we enter something in /etc/hosts.
I was concerned we had some rouge boxes or systems, we are not a large company, but have a number of systems running, thought maybe someone's phone or tablet may have had some extension installed that could have been causing this.
We configured some Sflows to monitor traffic to Google, but the traffic was not showing any strange use or a high number of requests for searches.
I did a check also from my hosted servers that have tunnels and all of the same issues.
I would hope that Hurricane Electric might be aware of this problem and get some communication into Google support. We are a business customer and Google refuses to speak to us on this issue.
]I guess it would be best to put in a ticket into HE, I do know, HE responds very quickly to requests or concerns.
Quote from: linuxsrc on June 21, 2023, 07:15:13 AM]I guess it would be best to put in a ticket into HE, I do know, HE responds very quickly to requests or concerns.
Not so much lately. I've sent them a message a couple of weeks ago on a different issue, they did respond by saying go deal with it yourself, refusing to answer any follow up question. Today, I emailed them about this and there was 0 response in the few hours since. Finally, when I asked them about the captcha situation 3 weeks ago, they said they are talking to google or so but apparently that didn't work out after all.
I'm really wondering if this is the end for my IPv6 with HE. I have a customer that using HE and I use it as well. I hope this is not the case as I can't get a /64 with CenturyLink. I'm in Denver, USA.
It would be nice if HE posted status updates on this thread.
I can confirm. I am having the same issues with Google responding with a 403 for all base URLs. I also had it forcing re-captcha for a couple weeks.
Same here, 403.
I didn't realize that the re-captcha issue was caused by this (till now)
Same problem here (reCaptcha and 403 now). Got the following reply after contacting HE at ipv6@he.net:
QuoteThank you for reaching out. We are aware of the issue and are working with Google to resolve it.
I had to disable the tunnel again (https://forums.he.net/index.php?topic=4248.msg23166#msg23166) as this was becoming problematic, and I did not feel inclined to start trying to hunt down every possible Google domain in order to put a firewall rule in place to block them.
I had not yet visited here yet so I didn't know if others were experiencing the same, but I also started to get numerous "403 Forbidden" errors as well from Google when attempting to use Google Search via IPv6. This followed a few months of getting forcibly signed out of Google Workspace accounts due to what Google termed as "suspicious activity" (though I could not identify anything), and experiencing numerous reCAPTCHA requests from Google last week.
searching is again broken 403, Forbidden
What I do with Firefox is about:config | network.dns.ipv4OnlyDomains
Enter: .google.com
There is no setting in Chrome that I know of to do this same function.
This is very annoying on Android phones. On Android you can switch to Firefox Beta and enter that setting.
This type of stunt from Google is disgusting and shows what a "heavy hand" they have.
Same issue here. There's a setting in Chrome Enterprise version, https://chromeenterprise.google/policies/#BuiltInDnsClientEnabled that disables chrome's built-in DNS client. You also have to disable https://chromeenterprise.google/policies/#DnsOverHttpsMode policy as well. At that point I speculate that if you do a DNS resolver override on your firewall (if you have that option) to point the google.com domain at an external IPv4 resolver such as 1.1.1.1 it may force the connection down to IPv4 outside the IPv6 tunnel. Haven't tried it yet but plan to in the next few days. Very frustrating, and I agree, Google has gone fully off the rails on this. Side note, HE.net support has been very quick to respond to my support emails. Hopefully they have some luck getting Google to change this back. Otherwise it's DuckDuckGo FTW.
Same via EE broadband in the UK. Tunnelbroker connections to Google search come back with error 403. Turning off IPv6 in the client, leaving IPv4 only, restores working page.
Quote from: Jenick on June 21, 2023, 09:20:44 PMAt that point I speculate that if you do a DNS resolver override on your firewall
Simply blocking AAAA resolution for *.google.com (and optionally *.google.<country_code>) in Unbound resolver (plus blocking/disabling DoH/DoT) on firewall works, leaving IPv6 usable for the rest of the net. People using pfSense + pfBlockerNG can test this easily.
Same here. Google searches do not work for me over my HE assigned IPv6.
I get the 403 "Your client does not have permission to get URL" message.
A week or two ago, I was getting a different error message but I didn't write it down.
Google searches over an IPv4-only machine work fine.
I'm not sure what everyone is using for a firewall. I'm using OpenBSD. For the purposes of this discussion it might as well be a variant of pfSense (https://www.pfsense.org/) / opnSense. (https://opnsense.org/). When I had to deal with the netflix problem, I went with defense-in-depth and stopped quad-A searches for netflix's domains. As a second layer, I also added all of their IP space relative to me to a table. I block new connections at my edge to addresses in the table with a TCP RST / UDP port unreachable. The pros and cons are: pro - this plays well with happy eyeballs; the target never sees traffic from HE's ASN coming from your tunnelbroker space; cons - the addresses that you are blocking are dynamic so you need to have a mechanism to keep them up to date; you also may be blocking content temporarily that you don't need to block. I added manually added www.google.com to this space when this first started happening since I hoped that the problem would get resolved. Apparently, it hasn't so I'll have to automate this process.
I'd bet dollars to donuts that some a**hat has found a way to abuse the tunnels again and is causing problems for google and this is just a response. This was the case with Netflix and it's also the problem with Wikipedia. As such, I think that we are going to be dealing with problems like this until IPv6 is much more relevant. Right now, kick/banning an entire ISP is an easy way to deal with the abuse if you look at it from the application provider's side.
Quote from: cshilton on June 22, 2023, 09:08:56 AMRight now, kick/banning an entire ISP is an easy way to deal with the abuse if you look at it from the application provider's side.
Right now, Google has got pretty much a monopoly in the search engines market. Similar behavior is completely unacceptable. Apparently, they are asking for more trouble in the EU.
Quote from: cshilton on June 22, 2023, 09:08:56 AMI'm not sure what everyone is using for a firewall. I'm using OpenBSD. For the purposes of this discussion it might as well be a variant of pfSense (https://www.pfsense.org/) / opnSense. (https://opnsense.org/). When I had to deal with the netflix problem, I went with defense-in-depth and stopped quad-A searches for netflix's domains. As a second layer, I also added all of their IP space relative to me to a table. I block new connections at my edge to addresses in the table with a TCP RST / UDP port unreachable. The pros and cons are: pro - this plays well with happy eyeballs; the target never sees traffic from HE's ASN coming from your tunnelbroker space; cons - the addresses that you are blocking are dynamic so you need to have a mechanism to keep them up to date; you also may be blocking content temporarily that you don't need to block. I added manually added www.google.com to this space when this first started happening since I hoped that the problem would get resolved. Apparently, it hasn't so I'll have to automate this process.
I'd bet dollars to donuts that some a**hat has found a way to abuse the tunnels again and is causing problems for google and this is just a response. This was the case with Netflix and it's also the problem with Wikipedia. As such, I think that we are going to be dealing with problems like this until IPv6 is much more relevant. Right now, kick/banning an entire ISP is an easy way to deal with the abuse if you look at it from the application provider's side.
I'm on pfSense Plus 23.05 latest release with the latest patch set. There's an option in pfBlockerNG under DNSBL Python mode to disable AAAA lookups against a list right there in the UI. I just spotted it, enabled it, and added www.google.com and google.com to the list. Got google access back now, not that we use it much anyhow but we do sometimes go there when duckduckgo isn't giving enough relevant results. Hope this helps some pfSense users. I'm not sure if the pfSense CE 2.6.0 version has this option since that version used to require the pfBlockerNG-devel branch package to get the extra features. It's easy enough to upgrade to 23.05 Plus from CE 2.6.0 anyhow for personal use. Even with a work-around place, HE.net has to continue the pushback on Google to STOP doing this crap!
Quote from: Jenick on June 22, 2023, 09:21:55 PMQuote from: cshilton on June 22, 2023, 09:08:56 AM...snip...
I'd bet dollars to donuts that some a**hat has found a way to abuse the tunnels again and is causing problems for google and this is just a response. This was the case with Netflix and it's also the problem with Wikipedia. As such, I think that we are going to be dealing with problems like this until IPv6 is much more relevant. Right now, kick/banning an entire ISP is an easy way to deal with the abuse if you look at it from the application provider's side.
I'm on pfSense Plus 23.05 latest release with the latest patch set. There's an option in pfBlockerNG under DNSBL Python mode to disable AAAA lookups against a list right there in the UI. I just spotted it, enabled it, and added www.google.com and google.com to the list. Got google access back now, not that we use it much anyhow but we do sometimes go there when duckduckgo isn't giving enough relevant results. Hope this helps some pfSense users. I'm not sure if the pfSense CE 2.6.0 version has this option since that version used to require the pfBlockerNG-devel branch package to get the extra features. It's easy enough to upgrade to 23.05 Plus from CE 2.6.0 anyhow for personal use. Even with a work-around place, HE.net has to continue the pushback on Google to STOP doing this crap!
OpenBSD is distantly related to, and more primitive than pfSense and opnSense. It's like the OS from those products without the web based UI.
Your solutions is much simpler than mine, would you mind posting it to the general solutions thread (https://forums.he.net/index.php?topic=4263.0) - https://forums.he.net/index.php?topic=4263.0 so that other people only have to look in one place to find it?
Quote from: cshilton on June 23, 2023, 07:12:32 AMQuote from: Jenick on June 22, 2023, 09:21:55 PMQuote from: cshilton on June 22, 2023, 09:08:56 AM...snip...
I'd bet dollars to donuts that some a**hat has found a way to abuse the tunnels again and is causing problems for google and this is just a response. This was the case with Netflix and it's also the problem with Wikipedia. As such, I think that we are going to be dealing with problems like this until IPv6 is much more relevant. Right now, kick/banning an entire ISP is an easy way to deal with the abuse if you look at it from the application provider's side.
I'm on pfSense Plus 23.05 latest release with the latest patch set. There's an option in pfBlockerNG under DNSBL Python mode to disable AAAA lookups against a list right there in the UI. I just spotted it, enabled it, and added www.google.com and google.com to the list. Got google access back now, not that we use it much anyhow but we do sometimes go there when duckduckgo isn't giving enough relevant results. Hope this helps some pfSense users. I'm not sure if the pfSense CE 2.6.0 version has this option since that version used to require the pfBlockerNG-devel branch package to get the extra features. It's easy enough to upgrade to 23.05 Plus from CE 2.6.0 anyhow for personal use. Even with a work-around place, HE.net has to continue the pushback on Google to STOP doing this crap!
OpenBSD is distantly related to, and more primitive than pfSense and opnSense. It's like the OS from those products without the web based UI. Your solutions is much simpler than mine, would you mind posting it to the general solutions thread (https://forums.he.net/index.php?topic=4263.0) - https://forums.he.net/index.php?topic=4263.0 so that other people only have to look in one place to find it?
I'll do that but have to test a few more computers and devices with the change in place. It seems to work only if you implement the chromium/firefox tweaks to disable the browser's built in DNS client DOH/DOT. Our iPhones/iPads are still getting the block error even with the pfSense pfBlockerNG changes in place because they're likely resolving via their own built-in DNS client implementations. This is so frustrating!
Yeah, I recall attempting OpenBSD about 15 years ago, had some luck getting it up and running but ended up going with pfSense when it first came out and just stuck with that. I'm mainly a Linux/Windows/VMware/Cisco guy. I can manage my way around the FreeBSD cli side of pfSense but only go there as needed. So, more frustration, I just rebooted my iPhone, then hit google.com no issues inside the duckduckgo browser app. As soon as I tried hitting it in the Safari browser I got kicked again. So iOS is caching the IPv6 from the Safari attempt and then I get kicked from duckduckgo app on the next attempt. This is ridiculous! Here we are downgrading security, kludging work-arounds, etc. all to visit a search engine that's become way too involved in our private lives. I'll still post the work-arounds I put in place likely over the weekend.
Quote from: Jenick on June 23, 2023, 10:55:18 AM...snip...
I'll do that but have to test a few more computers and devices with the change in place. It seems to work only if you implement the chromium/firefox tweaks to disable the browser's built in DNS client DOH/DOT. Our iPhones/iPads are still getting the block error even with the pfSense pfBlockerNG changes in place because they're likely resolving via their own built-in DNS client implementations. This is so frustrating!
A combination of your fix and my fix might do it for the clients where DNS blocking isn't working. I don't have enough experience with pfSense to figure out how to to modify the ruleset by hand though. I do wish that I knew how to turn off DNS over https for my network from a central place. It appears that blocking or redirecting ports 53 and 853 will do that for DoT. As far as I'm concerned DoH is a bandaid that's an unfortunate requirement for those people not running a proper DNS resolver on their network. But, running a DNS resolver is hard so most people don't do that in their home networks and I get this.
Quote from: cshilton on June 23, 2023, 11:46:25 AMQuote from: Jenick on June 23, 2023, 10:55:18 AM...snip...
I'll do that but have to test a few more computers and devices with the change in place. It seems to work only if you implement the chromium/firefox tweaks to disable the browser's built in DNS client DOH/DOT. Our iPhones/iPads are still getting the block error even with the pfSense pfBlockerNG changes in place because they're likely resolving via their own built-in DNS client implementations. This is so frustrating!
A combination of your fix and my fix might do it for the clients where DNS blocking isn't working. I don't have enough experience with pfSense to figure out how to to modify the ruleset by hand though. I do wish that I knew how to turn off DNS over https for my network from a central place. It appears that blocking or redirecting ports 53 and 853 will do that for DoT. As far as I'm concerned DoH is a bandaid that's an unfortunate requirement for those people not running a proper DNS resolver on their network. But, running a DNS resolver is hard so most people don't do that in their home networks and I get this.
Yep, exactly! The Google GPO policy settings I mentioned previously will disable DoH globally in the chromium-based browsers. I'm not sure if Microsoft's Edge version has the same config settings. I know Chrome and Brave both work fine with the policies in place as both of those hit google.com no problem now for me. For enterprises it's fairly simple, if they have AD in place and healthy, with DCs running 2016 or 2019 server and the domain and forest functional levels set at least to 2012R2 they can simply download the Chrome GPO ADMX templates into their central policy directory and make the changes inside a GPO. Brave might be more difficult, I'm not sure they have ADMX templates. Smaller shops could do it with a powershell script by creating the proper registry keys and values then push that out as a startup or logon script.
This is the basic script I use at home on our PCs:
# This assumes you have winrm enabled on all the computers and can remotely execute powershell commands.
#
# This will enable winrm but might require a visit to each PC, or use of Sysinternals Suite psexec:
# winrm quickconfig
# Set-Service -Name WinRM -StartupType Automatic
# Start-Service -Name WinRM
# Disable Google Chrome DoH and the built-in DNS client to force OS lookups.
# Get an Administrator level windows credential for the domain joined PCs, or,
# if in WORKGROUP mode an admin account that has the same name and password on all computers in the workgroup.
$cred = Get-Credential
Invoke-Command -ScriptBlock {
New-Item -Path 'HKLM:\Software\Policies\Google'
New-Item -Path 'HKLM:\Software\Policies\Google\Chrome'
New-ItemProperty -Path 'HKLM:\Software\Policies\Google\Chrome' -Name 'DnsOverHttpMode' -Value 'off' -PropertyType String
New-ItemProperty -Path 'HKLM:\Software\Policies\Google\Chrome' -Name 'BuiltInDnsClientEnabled' -Value 0x0 -PropertyType Dword
} -Credential $cred -ComputerName PC01,PC02,PC03
# For Brave browser it would be:
Invoke-Command -ScriptBlock {
New-Item -Path 'HKLM:\Software\Policies\BraveSoftware'
New-Item -Path 'HKLM:\Software\Policies\BraveSoftware\Brave'
New-ItemProperty -Path 'HKLM:\Software\Policies\BraveSoftware\Brave' -Name 'DnsOverHttpMode' -Value 'off' -PropertyType String
New-ItemProperty -Path 'HKLM:\Software\Policies\BraveSoftware\Brave' -Name 'BuiltInDnsClientEnabled' -Value 0x0 -PropertyType Dword
} -Credential $cred -ComputerName PC01,PC02,PC03
Quote from: rdunkle84 on June 21, 2023, 06:16:39 PMThis type of stunt...
This isn't a "stunt". It's how their AUTOMATIC processes work. Bad stuff happens, the "AI" looks up the address (WHOIS), and arrives at a /48. Bingo. The pool from which thousands of tunnel routed /64's goes poof. Even if they block the /64, the baddie will just get another one.
Good luck getting either HE or Google (ESP. GOOGLE!) to do anything about it. Not that HE can... anyone can get an account, and setup tunnels.
(If enough /48's get tagged, the entire /32 allocation will be blocked. But I don't know what that threshold is.)
Hi there,
Just to confirm the same behaviour with Google in Latvia. Just tested again, and got 403 error on ipv6.google.com. Sad but true.
Has there been any official comments or ticket from HE regarding the status of this? For now I've just disabled IPv6 for myself and two other customers.
Quote from: ChrisDos on July 03, 2023, 04:52:06 AMHas there been any official comments or ticket from HE regarding the status of this? For now I've just disabled IPv6 for myself and two other customers.
Not a word. I likewise have an entry in DNS to do the following:
private-address: 2607:f8b0::/32
I have the pfSense successfully filtering Google by adding a rule to reject any traffic going to its IPv6 ranges:
1. Create a firewall ip alias with the ipv6 addresses from here: https://md5calc.com/google/ip
2. Create a reject rule on your LAN interface for IPv6, source any, destination single host or alias and point to your Google alias.
3. Save and apply.
Job done.
By the way, I have a similar rule for Yahoo mail, which did not want to play ball with IPv6 either.
Quote from: kpanchev on July 04, 2023, 02:13:41 PMI have the pfSense successfully filtering Google by adding a rule to reject any traffic going to its IPv6 ranges:
Until HE fix things with Google, this seems to be the best solution by far. I was able to do the same, setting up a "Networks" alias (https://docs.opnsense.org/manual/aliases.html) on my OPNsense firewall. It avoids having to mess with any specific app to disable DNS over TLS/HTTPS etc. Properly coded apps that find they can't connect over IPv6 should transparently fall back to IPv4 and that's what I've seen with all clients on my network so far.
It's seems to Google working again through v6 tunnel... can anyone confirm?
Quote from: Volui on July 10, 2023, 06:29:09 PMIt's seems to Google working again through v6 tunnel... can anyone confirm?
Yes, I confirm
support advises to switch to /48 to avoid google bans in future.
Quote from: anzial on July 12, 2023, 04:02:38 AMsupport advises to switch to /48 to avoid google bans in future.
Well, the thing is, we've already been using /48s everywhere before this happened. Anyway, seems to be working for now.
Quote from: anzial on July 12, 2023, 04:02:38 AMsupport advises to switch to /48 to avoid google bans in future.
Do you mean block outbound connections to Google at the xxxx:yyyy:zzzz::/48 level? Or, are you saying that Google has not banned Hurricane Electric at the 2001:470::/32 level and a tunnelbroker 2001:470:xxxx::/48 customer assignment may not be in the banned range? I ask because as I understand it, Netflix is flagging anything from 2001:470::/32 as coming from via a proxy. I understand that they are two different companies here but I compare Google and Netflix because both are implementing a control policy for communications coming into into their network. I had made the possibly wrong assumption that Google is blocking 2001:470::/32.
can't tell you the precise wording about /48 subnet from support, the effing google now signed me out of my email account and forcing to wait for a restore email (it happened after I tried to setup /48), but yeah, it was something about google banning whole subnets but /48 might reduce chances of it happening in future to a specific user as opposed to using /64.
It seems that Google fixed it, I can now access google.com search without any captchas and without error 403.
I was getting the captcha for a while but it stopped but today I got the following email from HE Support:
Hello,
Your tunnel has been seen as a source of automated google-services scripting behavior without adhering to Google's /robot.txt file.
Please stop all automated or non-human activities google's services through our tunnel services or your account will be disabled/removed.
Please let me know if you have any questions.
Thanks,
Hurricane Electric Support
I've replied back asking for the IPs but I don't have anything configured to use google-services and I'm pretty sure I don't have any malware doing it. Has anyone else seen this?
Support responded, Google is only giving them the /64 subnet but not the actual IP. Google is being very agressive which is hypocritical because their bots don't honor /robots.txt.
I just blocked any outgoing IPv6 traffic to Google's /32.
I too got an email asking to stop all automated or non-human activities toward Google's services. I asked for more details as there should be no such thing on my network and in fact, most devices are configured to use DuckDuckGo anyway.
I have a theory. I wonder if all this is happening because a lot of GeoIP databases get our Geo's wrong. For me, I show up as RUSSIA.
well, it took mere 2 months for this to start all over again. Just recaptcha for now, full ban will follow probably again. Worked fine just 12 hours ago.
Indeed, got my first captcha again this morning :(
Опять началось. школьные автобусы, велосипеды и пешеходные переходы
I have to #metoo this.
I tried amsterdam and london tunnel servers. Both give me google captcha.
Google is not prepared for ipv6.
They censor.
Quote from: michielbruijn on September 06, 2023, 08:18:03 AMGoogle is not prepared for ipv6.
They censor.
They simply block huge ranges of addresses they don't like - without a reason.
I switched to another search engine - not only because of that.
Other Google Services seem to work.
Quote from: michielbruijn on September 06, 2023, 08:18:03 AMGoogle is not prepared for ipv6.
They censor.
Considering that Google is likely the largest provider that actually supports IPv6 (as Amazon AWS doesn't even fully support it yet across all of their services), this is a patently false statement. Also, "they censor" does not mean what you seem to think it means here.
The problem, as far as things seem to go, is that malicious actors are making use of HE's tunnelbroker service, and Google's viewpoint is likely that it's easier to tarpit (by way of reCAPTCHA, in this case) 2001:470::/32 than to play whack-a-mole.
It's in no way dissimilar to how practically every known Tor exit node is also similarly hit with a tarpit, if not outright blocked by some services - in order to block bad actors. That's not censorship, that's network management.
With respect to persons abusing HE.net's IPv6 TunnelBroker service, this is an issue that HE.net needs to resolve. The problem is that their absolute silence on this forum for months has been deafening; and if their interactions - or rather lack thereof - on this board given that this thread alone has been going since May are any indication of the response they've probably given to Google, then it is no wonder that Google took such an action. We all get to feel the ramifications of that.
Side note, for anyone running their own DNS, or who wants to disable IPv6 to Google, either of these two comments will help:
* https://forums.he.net/index.php?msg=23250
* https://forums.he.net/index.php?msg=23251
#metoo again - and yeah, the IPv6 no-AAAA hack still works.
Sigh.
Quote from: doktornotor on September 08, 2023, 01:03:18 AM#metoo again - and yeah, the IPv6 no-AAAA hack still works.
More details please
If it helps, HE.net support told me to change my LAN side networks to my /48 routed, not the /64 default they hand you when you first created your tunnel. However, if you're running pfSense and pfBlockerNG you can give this a try... https://github.com/pahtzo/hurricane-tunnel-dohdot The main issue I believe is chromium based browsers have their own built-in DNS client which automatically goes for DOH-DOT by default and maybe not even against your system based DNS servers. I've disabled my pfBlockerNG no-AAAA for google.com and www.google.com but retained my Windows 10 registry settings to disable the built-in DOH-DOT in Brave, Chrome, and Edge. Still working just fine.
I changed routed prefix to /48. Still works
Still no fixes for /64 routed?
I'm getting google captcha on my /48 now as well
getting google captcha on /64
We began getting goog recaptchas maybe a week ago. Have one routed /64 from the allocated /48 network in use at home. And... just now I got a abuse complaint from HE, forwarding a goog complaint stating "We are seeing automated scraping of Google Web Search from a large number of your IPs/VMs.". No, none such going on.
Has HE been working with Google on this? I have a couple of customers using 6in4 and this is very annoying. Why can't Google see the benefits of this.
Edit: Still not working of December 27th. Uggg.
I'm "guessing" that HE is not working on it more than forwarding the complaint to the users, hoping that the few accounts that perhaps were actually causing problems take steps to correct themselves. And then the big machine in the sky might stop the captchas... Uh.
I've had to stop using the HE IPv6 Tunnel Broker at home for now.
Quote from: quite on December 28, 2023, 11:42:55 PMI'm "guessing" that HE is not working on it more than forwarding the complaint to the users, hoping that the few accounts that perhaps were actually causing problems take steps to correct themselves. And then the big machine in the sky might stop the captchas... Uh.
I notice that from 2001:470::/32 some scans occur and I contacted he's abuse desk.
I dunno if a relevant of abusers use their AS to query the Google search.
Although, Google is a company that doesn't care about the users if only a small amount of them is affected by their decisions.
I use another search engine (4get.plunked.party) that can also show results from Google.
This just hit me too...time to disable the tunnel :(
I first noticed this issue with Google search also, then it slowly spread across all Google Services, and now I basically find that the entire 2001:470:: address space, or maybe the entire HE.NET domain, is basically blacklisted.
I no longer get Captcha challenges, I am immediately met with HTTP 403 - Forbidden everywhere I go regardless of the browser, app, device, or operating system.
Netflix, Microsoft, Google, Apple, Samsung, Github, mozilla, live.com, Amazon, banks, paypal, ticketmaster, walmart, etc. I even get 403 errors in the browser console from advertising networks. Then things got worse, basically any site/app that uses cloudflare or AWS gives me a 403 error. Now I even get 403 errors from major DNS services - CloudFlare, GooglePublic DNS, SafeDNS, OpenDNS, Quad9 are all blocking DNS requests of any type from my he.net tunnel.
Disabled the tunnel and all problems immediately disappear. Re-enable tunnel and problems return.
I tried deleting my tunnel then creating a new tunnel to different North American site with both /64 and /48 networks in order to obtain a new prefix. I have tried tunnels to Seattle/Beaverton, Fremont, Ashville, Denver, and Phoenix. They worked at first but all ended up the same after the first few hours.
Then add insult to injury I also found I could not create a AAAA DNS record that contained a he.net tunnel address because the DNS service provider said the address space is prohibited.
I finally just gave up and disabled IPv6 on my connection, then deleted my HE.NET tunnels in my account and I'm just going to let the account fade away.
Whatever.....
Quote from: cecilspiqwuc on January 25, 2024, 01:19:24 AMI first noticed this issue with Google search also, then it slowly spread across all Google Services, and now I basically find that the entire 2001:470:: address space, or maybe the entire HE.NET domain, is basically blacklisted.
I no longer get Captcha challenges, I am immediately met with HTTP 403 - Forbidden everywhere I go regardless of the browser, app, device, or operating system.
Netflix, Microsoft, Google, Apple, Samsung, Github, mozilla, live.com, Amazon, banks, paypal, ticketmaster, walmart, etc. I even get 403 errors in the browser console from advertising networks. Then things got worse, basically any site/app that uses cloudflare or AWS gives me a 403 error. Now I even get 403 errors from major DNS services - CloudFlare, GooglePublic DNS, SafeDNS, OpenDNS, Quad9 are all blocking DNS requests of any type from my he.net tunnel.
Disabled the tunnel and all problems immediately disappear. Re-enable tunnel and problems return.
I tried deleting my tunnel then creating a new tunnel to different North American site with both /64 and /48 networks in order to obtain a new prefix. I have tried tunnels to Seattle/Beaverton, Fremont, Ashville, Denver, and Phoenix. They worked at first but all ended up the same after the first few hours.
Then add insult to injury I also found I could not create a AAAA DNS record that contained a he.net tunnel address because the DNS service provider said the address space is prohibited.
I finally just gave up and disabled IPv6 on my connection, then deleted my HE.NET tunnels in my account and I'm just going to let the account fade away.
Whatever.....
Boy, I had not idea it had gotten that bad. I was waiting for it to clear up again before re-enabling it, but based on what you were saying, I don't think that is going to happen.
Time to look to see if there is another provider of of IPv6 tunnels. It sure is a lot of work on my end to switch everything over if an alternative exists.