@elmnts Yes, I'll certainly re-install when the next version appears, or soon after, probably on a day when I'm at home by myself, and I've got a few hours to do some testing without danger of upsetting my partner's television viewing or internet use! As I said, it isn't really urgent because I'm not running an environment where there is a particularly high risk of a user going somewhere they shouldn't or being hijacked, but it is nice to know the protection is there, particularly when life gets back to normal and we have visits from the younger family members who are all over social media!

@bbcan177 That was the reason, I had System > Advanced > Protocol set to HTTPs on the first system and to HTTP on the second. I changed to HTTPs on the second system, ran a PfBlockerNG update and aliases URLs changed to HTTPs too ;-) Many thanks !

@bbcan177 I get that it's a complicated process, but what is being taxed? Is it all loaded in RAM and it's the RAM speed limiting it? I have the same problem with Quickbooks in every install we've done. It's runs slow but nothing we see is being overly taxed. If I were to build a new system and upgrade from the APU2 units, what would need to be sped up to alleviate the issue?

@viktor_g thanks, but no , that was not it, it was a post that handle cases where maxmind did not work, it include edit some conf file on pfsense + running some PHP files, to rebuild the DB

@johnpoz done and seems to be working.... thanks

@bbcan177 said in pfBlockerNG & Squid transparent proxy: localhost It was already in localhost. pfBlockerNG works with both pfBlockerNG & Squid running. However, Squid 'transparent' proxy is not working. If I can configure proxy settings in my browser then I can see Squid proxy is getting the URL request & virus scanner running. I suspect transparent proxy is conflicting with pbBlockerNG

@talaverde HA is a complex animal, some interfaces use CARP VIPs and packages use the XMLRPC to sync. XMLRPC has issues where you can use a dedicated user and some vendors(Snort/Cisco) did not think you could do that so they force you to use root/admin to sync your data.

@bbcan177 Thank you, thank you, thank you!!! The "Suppression" option was disabled and enabling fixed the problem. The 192.168.1.1 IP is now begin removed from the URLhaus blacklist. I think I also now understand the ALIAS solution. I would need to convert ALL pfB lists to aliases and completely forgo the auto rules. This seems to be good practice in general and I may consider this. Finally, I do plan on updating to the devel version eventually, probably when I update to pfSense 2.5.0 in the future. This will take some time and I need to make sure I carve the time out from my schedule to address the issue. Right now, I am too busy at work and need the internet to just work for my video conferences.

@mcury I am just adding each Vlan to the "Outbound Firewall Rules" under the IP tab in pfBlockerNG. Then Each Vlan has this rule towards the top before the block firewall/Internal rules [image: 1609993918639-7475b17a-506b-4c43-b709-0b0650b33fc0-image.png]

@teamits I did not. It halted during boot and led me to a "#" prompt

@bbcan177 Confirmed. It was the 6 hours time difference.

@bbcan177 said in pfBlockerNG v3.0.0_6 update: Add preliminary DNSBL Group Policy configuration that will globally bypass DNSBL for the defined LAN IPs Thank god for this new functionality, thank god! (well, thank bbcan177!!!) Sure looking forward to the CIDR notation

It appears to be working now that the cache is cleared, thanks.

@bbcan177 work perfect

Thank you @BBcan177 for confirming your (eventual) plan and @Gertjan for the graphic picture. :-)

@griffo @ronpfs in my case things have gotten more interesting. I can see a restart before each outage. So this suggests an unplanned reboot happening about once a week pfblockerng or unbound does not start up correctly upon restart #2 is fixed by re-starting pfblockerng but #1 will need more digging. It's easy to see if this is happening by checking NTP logs (search for "Starting") or system logs. The reboot is interesting. In all three cases LAN was fine, WAN was knocked out by the restart, CPU temps are very good, and in at least two of the cases I was making network adjustments through the unifi UI for my access points at the time that things went down. Possibly coincidence.