@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.. [image: 1674913729538-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 [image: 1674768042247-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).

Just verified this on 2 boxes each after a fresh re-flash back to pf 22.05 after changing repos on the updates tab corrupted my conf files and then led to persistent certificate errors at boot, going back to restore configurations I ran into this on each, and in IPv6 whitelists as well. Config.xml restoration went smoothly and re-installed the packages after fine also. Previously saved IP whitelists I created in 21.05 that I haven't edited since show the correct configuration settings when I inspect them inside pfblocker and verified are still working at the auto generated firewall rules in creates. Verified still present in pfblockerng-devel 3.1.0_9, I can no longer edit nor can I create any IPv4/IPv6 whitelist with the available "permit inbound" or "permit both" options as they previously used to function. "Alias permit" does work though with manually configuring a new firewall filter for the alias. Just located this after posting about it too: BBcan177BBcan177 MODERATOR 12 days ago @bob-dig @cjbujold See the patch here and report back pls. From the Shell or pfSense GUI > Diagnostics > Command Prompt > Execute Shell Command, run this command to download the patch. curl -o /usr/local/www/pfblockerng/pfblockerng_category_edit.php "https://gist.githubusercontent.com/BBcan177/1a33c42d0a61f3ddd9c2f1b1d514ed83/raw" "Experience is something you don't get until just after you need it."

@nogbadthebad that is odd nslookup behavior.. oh tip on windows, you could try adding . as the search suffix.. since it won't let you use nothing.. this seems to quiet it down.. Atlease from respect of nslookup debug.

@yquirion I was surprised as well and was hoping it did not change my configuration which it did not. I was not aware about querying the database so I learned a very nice thing from you as well.

@gpinzone ? Have a look at a DNS packet unbound receives on the pfSense LAN port. Yep, that will be an Ethernet packet. As filter criteria, set up port 53, and use the IP of your device. As soon as you have one, inspect it. This is technology of the years 60 and 70, last century, so quiet simple. You will find out quickly there is a source IP, destination IP, source port, destination port, and a 'word' with 16 or so bits that tells what kind of packet it is (like UDP - the packet number etc) and a time stamp. There is no information that tells unbound "what program" made or send this packet *** So, unbound on pfSense can not know that the packet creating program was a 'browser' (or a mail client, or command line tool, or a file server, or a mail server, or whatever program) that wants to communication over the Internet. With some very nifty comparing you could speculate what OS made the packet. Programs exist to do this kind of detecting. Unbound can't do that. What you can do : tell your browser to do its own DNS, so addresses itself direcly to, for example, 8.8.8.8 or a "canary" solution.

@bbcan177 Hey thanks for your efforts, any luck with the patch specific to saving port alias for Geo IP as well.