@steveits I use 22.05 with 3.1.0_11. The cron process is not stuck but the pfbkockerng.php comes up randomly. I can kill it via console and later it's back on again - before the cron time. I removed my MaxMind key. For now I haven't experienced cpu spikes.

@gertjan

oh wow, awesome, that's exactly what I wanted! Works perfectly!

Thank you!

@keyser oh thank you very much for helping! now I feel really dumb, I swear I've looked at that page a dozen times!

Ended up working in this thread

https://forum.netgate.com/topic/177212/pfblockerng-devel-v3-1-0_19-10/76

To get resolution and there was a hung upgrade between 23.01 Beta and 23.01 RC that held back the unbound version which kept me on the old python version.

Running pkg upgrade via shell and rebooting fixed all of my issues.

@johnpoz Thank you for the quick response, understood, OK, can squid transparent proxy and pfblocker coexist? Would you advise using squid guard or just regular squid? I've never installed the packages before but will try get them to co-exist.

@steveits said in Geoblocking the world except for home:

@nogbadthebad Since you showed "alias permit" just be aware that reportedly de-dupes across other permit or deny lists. There was a thread last year sometime where someone pointed out IPs were being removed. Alias Native will leave the lists unchanged.

Cheers I've changed them :)

@freph533

@freph533

I think I figured it out after reading some other posts. I was using a "real" domain name in System>General Setup and that was somehow causing this issue. I set it back to "home.apra" and it works fine now. I'm not sure how to get a "real" domain to work. Maybe I need a "Domain Override" or something in the DNS Resolver to get a real domain to work?

Anyways, for now, setting back to something like arpa, localdomain, etc worked to resolve this issue.

screenshot.jpg

Hope that helps!

@lk777 That IP is in there.

But that is not your isp space.. that is owned by rackspace

NetRange: 69.20.0.0 - 69.20.127.255 CIDR: 69.20.0.0/17 NetName: RSPC-NET-4 NetHandle: NET-69-20-0-0-1 Parent: NET69 (NET-69-0-0-0-0) NetType: Direct Allocation OriginAS: AS10532, AS33070, AS19994, AS27357 Organization: Rackspace Hosting (RACKS-8)

Your isp owns this space for example

NetRange: 69.112.0.0 - 69.127.255.255 CIDR: 69.112.0.0/12 NetName: NETBLK-OOL-6BLK NetHandle: NET-69-112-0-0-1 Parent: NET69 (NET-69-0-0-0-0) NetType: Direct Allocation OriginAS: AS6148 Organization: Optimum Online (OPTO)

Your IP that you talk to the forum is in that space - its not in a 69.20/16

And both of those ranges are in the geoio db that pfblocker downloads for US space..

ranges.jpg

You understand it condenses down ranges the so might not always be a exact cidr match, but your isp space in that range is included in that 69.112/12 (69.112.0.0 - 69.127.255.255) and that other US space you mention that is not your isp, is also included..

As to it being 100% accurate - you understand IP space moves around right.. Global companies, IP space is rented and sold, transferred to other companies... There is no freaking way its 100%

https://support.maxmind.com/hc/en-us/articles/4407630607131-Geolocation-Accuracy
It is not possible for us to guarantee 100% geolocation accuracy.

@motivio lets get that pcap started on pfsense.
Not sure how often it's querying for snapchat but let it run until the alert in pfblocker comes up.
Make sure count is set to 0
Stop the capture
Download the capture
Open the capture
search for the string in the capture. Edit > Find Packet > Set to string

0a9cbe25-36eb-4bb1-9944-8306efaa8b03-image.png

@jdeloach
Yes, of course. :-)

@gblenn Thanks to you,
I just turned off the floating rules.
I think it will work.

It's now been more than a month and this issue seem to be resolved. The only significant change was to stop using floating rules for pfBlocker.

@manilx I did run the commands from the above referenced post:

cd /usr/local/share/GeoIP /usr/bin/tar -xzf GeoLite2-Country.tar.gz --strip=1

Fixed this for the time being. As I'm running the latest .11 pfblockerng update I do think that this issues has been fixed. The only thing was that installing the update didn't also run the command, which I think it should.

@BBcan177 , @smoke_aj, Good news, I assigned the DNSBL webserver to localhost instead of the DMZ1 interface. Now everything is working and I am not seeing the error message again. Also after a filter reload the error stays away. So I guess as soon as you chose a physical interface (in my case LAN or DMZ1 or DMZ2) instead of localhost for the webserver, and in my case also a non default port number (8080 8443) and enabling Ipv6 the bug manifests itself. Can you replicate this behaviour ?

@nimrod Thanks for showing me where to delete. I won't bother you again.

@ssingh That’s going to take some “creative” configuration to work. PfSense comes with the UNBOUND DNS server which pfBlockerNG-devel modifies to answer DNS requests pr. Your allowed/denied lists. Adguard is another DNS filter service on its own, so now you have two competing services wanting to offer DNS services on port 53 - only one can prevail (seems adguard did in your case).
I would seriously recommend you keep adguard away from pfsense itself. It’s not designed to run on there, and pfSense’s default setup and UI settings expects its own services to resolve DNS.

Unless you know what you are doing, you’ll never get it to work as it would require quite at lot of “tinkering and custom setup”.

pfBlockerNG-devel can do everyting adguard does - you can even have it use the same blocklists, so there is no need for both.
So stick with that and stay away from the adguard service.

It you insist, then install adguard on a raspberry pi and have pfsense and unbound use that as an upstream DNS server (forwarding mode).