General solutions to the current google / 403 problem.

[cshilton]

I solved this with straight up boring packet filtering. My firewall is pf under OpenBSD so my solution should work under any firewall built against a recent pf with possibly minor syntax changes. The theory holds for any firewall that allows you match IP addresses against the values representing hosts and networks stored in a table. The pf firewall works top down so your block rules are usually at the top of your config.

Code Select Expand

## General firewall policy

block drop log all

...
pass on $v6_ext_if proto icmp6

...
table <no_ipv6_for_us> persist

...
block return in log quick on $int_if inet6 proto {tcp,udp} from ($int_if:network) to <no_ipv6_for_us>



The goal of the rule at the bottom is to prevent your clients from ever using IPv6 to reach hosts or networks hashed into the table no_ipv6_for_us. Those packets should be dropped with a TCP RESET. This should cause Happy Eyeballs at your client to conclude that whatever site you are addressing is currently IPv4 only. There are lots of ways to solve this problem. My network is somewhat large and I don't feel like running around to each client turning off IPv6 or changing the protocol preference from IPv6 to IPv4. For me, this seemed to be the best way to solve this problem.

Code Select Expand

$ dig +short AAAA www.google.com
2607:f8b0:4006:dead::beef
$ sudo pfctl -t no_ipv6_for_us -T add 2607:f8b0:4006::/48
1/1 addresses added.
$ sudo pfctl -k 2607:f8b0:4006::/48
killed 0 states from 1 sources and 0 destinations



The shell script above uses dig to find out what the current IP address of www.google.com where you are in the world. I'm assuming that Google is using different IP addresses in different places for the service. They may be doing tricks with routing to get you to closest server as a function of your physical location. I assumed that /48 is a good guess for the network size based on what I've seen in my DevOps career.

I still consider this to be problem that's going to get solved unlike Netflix and Wikipedia. I'm guessing that there's a bad actor in the wild and that she's figured out a way to influence Google's search results by flooding Google with a bunch of queries from different IP addresses. The bad actor has figured out that he can grab a new /64 or /48 somehow, possibly using the tunnelbroker api, and then spam Google from the resulting IP space. As with Netflix, HE will figure out a way to stop the abuse.

-- Chris

[Jenick]

I added a github repo with my powershell scripts to disable DoT/DoH in chromium-based browsers.  Also listed out some of my pfSense Plus and pfBlockerNG settings.  Repo here: https://github.com/pahtzo/hurricane-tunnel-dohdot

-Nick

[Jenick]

FYI, I added a few more items to the instructions related to the Unbound resolver.  Also corrected an issue in the remote Invoke-Command powershell script.  Just grab the new version if you cloned prior to 6/25/2023 at 3:00PM EDT.  https://github.com/pahtzo/hurricane-tunnel-dohdot

Nick

[troz]

Yeah. There's two options (assuming the "third" - turning IPv6 off - isn't on the table): (1) block the problem sites, and (2) fetch your own /48.

The issue with Google boils down to their standard process of run-everything-with-"AI". The routed /64 pool comes from a /48 (out of a /32 assigned block.) WHOIS data only goes so far as the /48. So Google's "smart" process is flagging the entire /48 for the actions of anyone's /64. Other site's automation tends to do the same thing. Even when there's a human behind it, the /48 will be blocked out of desperation. (block one /64, they just get another one... in seconds.)

#1 is a game of Whack-A-Mole. It might do what you want right now, but will be a problem in the future. (possibly because you forget it's there!)
#2 is really where we should all go. But I hate to "waste" that big a block of addresses.

(Even getting HE to add records down to the /64 won't necessarily fix anything.)