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 so that other people only have to look in one place to find it?
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!
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 / opnSense.. 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.
## 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>
$ 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
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.