More info here.... I'd like to add a page for this in the GUI, but too much to do with so little time.... https://www.reddit.com/r/pfBlockerNG/comments/9vwkmm/ip_ranges_for_amazon_aws/ ps - Come and subscribe to the reddit page :)

Hmm, I see. edit: Or at least I think I see. In the above example it’s only timing out when actually trying to talk (ping) to the resolved address. The lookup works fine. I don’t really see why that is a big issue since talking to a blocked domainname from PFsense itself should not be necessary anyhow. I mean, that doesn’t work now with the VIP adress either. You are only talking with an “empty” replacement Weebservice that has no data. Is there any situation where you are depending on the firewall itself needs to be able to ping the address? Anyhow Two things: 1: Could this issue be solved by making a VIEW in UNBOUND so the PFsense box itself is in another VIEW Zone with no PFblock.conf attached? 2: Alternatively, could “disabling VIP Alias” also entail that the PFsense box itself then is setup to NOT use the build in UNBOUND resolver?

Posted two PR to fix this issue. See my recent posts in this forum.

@guardian said in When is pfblockerNG-devel going to be pfblockerNG?: Any idea when pfblockerNG-devel going to be the production version? Likely Feb 2019

@ronpfs That was it!.. thx

@bbcan177 said in Unbound crashing: @bouke said in Unbound crashing: pfBlockerNG-devel 2.2.5_19 You can try the new "Live Sync" feature, which will update the changes on the fly without an Unbound Reload. But that is only when the package updates DNSBL/Unbound and not any DHCP updates to Unbound from the pfSense side. Happy new year and thanks. Just enabled this feature on 01-01-2019 08:05 am (local time) ;-)

I have already determined the cause of my problem. The lab workstation i was using to test this out with still had static DNS server entries configured on one of the network adapters I was using. Once I pointed them all to my pfsense box, everything was working fine. I feel stupid for having overlooked something so simple.

@gertjan said in Getting Hammered: I you liked the port-knocking on "22", have a look at what happens on your port "25" and "443", you'll be amazed. Seeing a few on 443 and a couple on 25. Normally, your mail server already has something like fail2ban and a rather huge setup to filter out fake connection, like temptation to relay, temptations to load your inbox with spams, etc. A (internal, on a LAN) web server (port 443) : same thing : a real hail storm. Not filtering these servers can put a real load on your servers. It is a Exchange server and not set up for routing mails and any attempt to route through it just gets rejected. I also have a large set of rules to reject spam but wanted to use pfBlockerNG to block out spamming IP's. YEs exchange can do it but requires the Edge Server to do it. Dont want another VM running to to do IP filtering. I realise they are scripts trying as well on the ports rather than real humans.

Thanks

Yes, you don't have to enable DNSBL.

Yea, it's been auto-changing back to often. I've finally given up on the 'CARP' feature and just switched it back to the old 'IP alias'. Not sure what features I'll lose but it can't be worse than a misconfigured virtual IP.

@mrglasspoole hi; I had to turn off ipv6 which i don't use(ignored in linux) and this is on a dual core AMD APU with 4 gigs. I also have issues with abuse list at first before killing ipv6 in pf latest and running out of ram issue. but at least it tells you and shuts down. but would like the caching squid had and av.

@bplein said in could not update pfBlockerTopSpammers: @ronpfs Thanks. It was in the Aliases/URLs section! Wow that was the old pfblocker version from over 4 years ago :)

@teamits said in Understand alert: yes Thanks for your thorough answer It clarified my question perfect!

@trohm said in Pass Alias for GeoIP not working: pfB automatically creates the rules and by default puts them in as Floating rules. Therefore I cannot put a rule ahead of the GeoIP rules as I understand Floating rules are always processed before any of the "static" rules applied to a given interface. You can select from one of the predefined Auto rule orders in the General tab (or in the IP Tab for pfBlockerNG-devel which is much improved). If one of those auto-rule options do not work for your network needs, you can use "Alias type" action settings, and manually create the firewall rules and associate the pfB aliastables. Click on the blue infoblock icons in the IP tab for more details.

Thanks @BBcan177, very much appreciated!