PfBlockerNG blocking Chrome's Data Saver
-
Currently, I am having a problem with external users accessing a website hosted in my intranet from their Android phones: they are not able to access the site because Chrome's Data Saver is enabled on its phone browser.
It took me some time to figure out why they were not able to access the site, but I found the source of the problem. When they use this browser resource, my website is accessed from Google's servers in North America. Since pfBlockerNG is set to block this continent (I am from Brazil), my users need to disable Chrome's Data Saver in order to access my intranet website.
This is not a problem at all, but it is a pain to instruct lay users that the problem is with their phone configuration.
Does anyone already experienced this problem? How do you recommend to solve it?
My best bet is to include Google Servers in a whitelist. What do you guys think? -
Here is a link for additional details…
http://serverfault.com/questions/662382/users-with-googles-ip-address-how-is-it-possible -
Here is a link for additional details…
http://serverfault.com/questions/662382/users-with-googles-ip-address-how-is-it-possibleIt does not help so much. Since pfBlockerNG block requests direct on the Firewall in a lower level, I do not think I am able to check any HTTP header to decide if that packet should be blocked or not.
For the record, here is my current solution:
-
pfBlockerNG > General
-
Rule Order: "| pfB_Pass/Match | pfB_Block/Reject | pfSense Pass/Match |"
-
I don't know why this is not already the default setting for pfBlockerNG. Without this, the Permit rules are useless.
-
-
pfBlockerNG > IPv4
-
Add a new alias:
-
Alias name: Google_IPv4_range
-
List description: Google IPv4 address ranges (https://support.google.com/a/answer/60764)
-
List action: Permit Inbound
-
Custom addresses:
64.18.0.0/20
64.233.160.0/19
66.102.0.0/20
66.249.80.0/20
72.14.192.0/18
74.125.0.0/16
108.177.8.0/21
173.194.0.0/16
207.126.144.0/20
209.85.128.0/17
216.58.192.0/19
216.239.32.0/19
172.217.0.0/19 -
All other settings keep the default.
-
-
-
pfBlockerNG > IPv6
-
Add a new alias:
-
Alias name: Google_IPv6_range
-
List description: Google IPv6 address ranges (https://support.google.com/a/answer/60764)
-
List action: Permit Inbound
-
Custom addresses:
2001:4860:4000::/36
2404:6800:4000::/36
2607:f8b0:4000::/36
2800:3f0:4000::/36
2a00:1450:4000::/36
2c0f:fb50:4000::/36 -
All other settings keep the default.
-
-
-
pfBlockerNG > Update > Force Update
Obviously, this configuration does not take in consideration eventual changes to Google's IP range. I don't know how dynamic this information is, so it would be wise to check and updated them regularly.
According to this link, you can get a list of current Google's IP ranges querying DNS TXT records from domains _netblocks.google.com, _netblocks2.google.com, and _netblocks3.google.com. This can be achieved from pfSense with the commands:
-
drill _netblocks.google.com @8.8.8.8 TXT | grep -vE '^(;|$)' | tr ' ' '\n' | grep ip | cut -d: -f2-
-
drill _netblocks2.google.com @8.8.8.8 TXT | grep -vE '^(;|$)' | tr ' ' '\n' | grep ip | cut -d: -f2-
-
drill _netblocks3.google.com @8.8.8.8 TXT | grep -vE '^(;|$)' | tr ' ' '\n' | grep ip | cut -d: -f2-
-
-
The link was just to help explain what was happening… pfSense/pfBNG won't see the x-forwarder IP, so you either have to whitelist the Google Proxy IPs, or put in a front-end like HAProxy and try to see if you can collect the x-forwarder IP and use a blocklist at that point... I am not sure if that is currently possible, but I believe there are solutions out there but it will take some extra effort on your part....
You have to do some research and see if you can find the Google Proxy addresses and automate that... You can also use "AS" numbers in pfBNG, but not sure if you can find just those proxy addresses...
-
You have to do some research and see if you can find the Google Proxy addresses and automate that… You can also use "AS" numbers in pfBNG, but not sure if you can find just those proxy addresses...
Yeah, I already did. I just created this script to automatically fetch Google's IP ranges:
#!/bin/sh PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin q="`drill _netblocks.google.com @8.8.8.8 TXT | grep -vE '^(;|$)' | tr ' ' '\n' | grep ip`" q="$q `drill _netblocks2.google.com @8.8.8.8 TXT | grep -vE '^(;|$)' | tr ' ' '\n' | grep ip`" q="$q `drill _netblocks3.google.com @8.8.8.8 TXT | grep -vE '^(;|$)' | tr ' ' '\n' | grep ip`" if [ "$1" == "" ] || [ "$1" == "ipv4" ]; then echo $q | tr ' ' '\n' | grep ip4 | cut -d: -f2- fi if [ "$1" == "" ] || [ "$1" == "ipv6" ]; then echo $q | tr ' ' '\n' | grep ip6 | cut -d: -f2- fi
But I set this script to generate two local files with the IP ranges at /var/db/pfblockerng/google_ipv4 and /var/db/pfblockerng/google_ipv6. But pfBlockerNG does not appear to be properly parsing these files. It only include the IP "1.1.1.1" to the alias when I force update.
-
Before you run "Force Update", delete the two files:
/var/db/pfblockerng/permit/pfB_google_ipv4 (Change permit and filename as required)
/var/db/pfblockerng/permit/pfB_google_ipv6 -
Before you run "Force Update", delete the two files:
/var/db/pfblockerng/permit/pfB_google_ipv4 (Change permit and filename as required)
/var/db/pfblockerng/permit/pfB_google_ipv6The error persisted. But I found where the bug is.
My list Header/Label was "Google IPv4" (with space). When I force update, it generates the "/var/db/pfblockerng/permit/Google IPv4.txt" file and I get the message:
... ===[ IPv4 Process ]================================================= [ Google IPv4 ] Downloading update .. completed .. Empty file, Adding '1.1.1.1' to avoid download failure. ...
I changed the Header/Label to "Google_IPv4" (space -> underscore) and now it is working as expected.