pfBlockerNG-devel v2.2.5_18
-
pfBlockerNG-devel v2.2.5_18 has been merged and approved by the pfSense devs.
CHANGELOG:
- PHPv7 improvements
- Improve some input validations
- Add Wizard Tool for default (entry level) installation.
4 clicks to an entry level installation of IP and DNSBL blocking protection!
https://www.patreon.com/posts/new-pfblockerng-22049064 - Add ASN Reporting functionality. This will collect the ASN for all IP events. The ASN will be in the Alerts Tab below the GeoIP value.
- Improve ASN -> IP Conversion function utilizing BGPview.io
- Improve Auto Rule Order functions
The Default rule order has been improved to put any pfB Permit rules first.
Please check your Rule ordering to ensure that the changes are working as expected! - IP Suppression default enabled on new installations
- Improve installation script and logging
- ZeroDot1 IP Feed (CoinBlocker) has moved to a subscription model. Feed Tab has been updated.
- Sync Tab - Added the IP Tab to the excluded XML sync option.
- Add DNSBL SQLite3 database validation functionality.
Any feedback appreciated!
Thanks!
Follow me here for more news about pfBlockerNG:
https://twitter.com/BBcan177
https://www.patreon.com/pfBlockerNG -
Thank you -
Ooops just saw that now ;)
-> https://forum.netgate.com/post/800911Great work so far!
Just reading:
4 clicks to an entry level installation of IP and DNSBL blocking protection!
Maybe my cluster setup but did the wizard, anything looks like it's enabled per default, but no rules are created on LAN. That's intentional?
-
@jegr said in pfBlockerNG-devel v2.2.5_18:
Maybe my cluster setup but did the wizard, anything looks like it's enabled per default, but no rules are created on LAN. That's intentional?
Re-run the wizard and ensure that the LAN Interface was selected... If it didn't apply a second time, might need to get some more details... Also check the pfblockerng.log if there are any other clues...
-
Alright, just a moment :)
Edit:
Done. Redid the Wizard. WAN and LAN were selected. After step 4 auto-updated triggered just like the first time. No errors in update log, completed normally. Afterwards were skimming through it and spotted it:
Unable to apply rules. Outbound interface option not configured.
But all interfaces in all screens relevant are configured?
-
@jegr said in pfBlockerNG-devel v2.2.5_18:
Unable to apply rules. Outbound interface option not configured.
After the wizard ran, is the Outbound interface selected in the IP Tab?
grep "<outbound_interface" /conf/config.xml -
Tried again:
- complete uninstall with keep settings UNchecked so full uninstall
- new install
- wizard, wan/lan selected, alternative ip 10.20.30.4 used (as the lan is within 10.10.10.x range)
- waited for updating
After 4) I checked wizard.log -> all clear, no errors.
Checked pfblockerng.log -> same error as above in between the update jobs.[ Talos_BL_v4 ] Downloading update .. 200 OK. completed .. ------------------------------ Original Master Final ------------------------------ 1382 1297 1297 [ Pass ] ----------------------------------------------------------------- *Unable to apply rules. Outbound interface option not configured. ===[ Aliastables / Rules ]========================================== No changes to Firewall rules, skipping Filter ReloadIn the IP tab:
- inbound: WAN IF is selected with option block
- outbound: LAN IF is selected with option reject
WAN/LAN don't have their standard "names", but are selected nevertheless. LAN is also selected as webserver IF in DNSBL tab.
-
I just updated an existing install of 2.2.5_17 to the new version and I to am having the same issue now. The previous version was working great.
I am also seeing the "Unable to apply rules. Outbound interface option not configured.". I checked and found the outbound interface options are still set correctly. All of my pfb aliases are now gone.
No errors in the logs that I can see.
-
@tagit446 said in pfBlockerNG-devel v2.2.5_18:
I just updated an existing install of 2.2.5_17 to the new version and I to am having the same issue now. The previous version was working great.
I am also seeing the "Unable to apply rules. Outbound interface option not configured.". I checked and found the outbound interface options are still set correctly. All of my pfb aliases are now gone.
No errors in the logs that I can see.I submitted a PR which is waiting on approval:
https://github.com/pfsense/FreeBSD-ports/pull/586Run this command to download a patched file:
fetch -o /usr/local/pkg/pfblockerng/pfblockerng.inc "https://gist.githubusercontent.com/BBcan177/15383a6b67b0b24154997a7ad5c3c66a/raw" -
@bbcan177 said in pfBlockerNG-devel v2.2.5_18:
fetch -o /usr/local/pkg/pfblockerng/pfblockerng.inc "https://gist.githubusercontent.com/BBcan177/15383a6b67b0b24154997a7ad5c3c66a/raw"
This appears to have fixed the issue.
It's seriously only been a few minutes since i posted, thanks so much for the speedy reply and fix!
-
@tagit446 said in pfBlockerNG-devel v2.2.5_18:
It's seriously only been a few minutes since i posted, thanks so much for the speedy reply and fix!
Your welcome!
-
I need to change the "CN_DNSBL" default self signed certificate by a one coming from my own internal certificate authority on lan network. Is it possible ? And how to do it ? By the GUI it looks impossible, so by entering console commands ? If you can help, thanks a lot !
I would also like to congratulate you on your excellent work on Pfblockerng ! -
@techedge59 said in pfBlockerNG-devel v2.2.5_18:
I need to change the "CN_DNSBL" default self signed certificate by a one coming from my own internal certificate authority on lan network. Is it possible ?
Yes, but what do you hope to accomplish with that? This will not prevent certificate errors on filtered https urls, if that is what you intend to do.
-
@grimson Know that... But my goals are:
1/ That all navigators in the lan, and especially Chrome, do not always ''alert'' the users cause of a self signed certificate. It's very important for us.
2/ Of course, then, if possible, remove the certificate error. -
@techedge59 said in pfBlockerNG-devel v2.2.5_18:
@grimson Know that... But my goals are:
1/ That all navigators in the lan, and especially Chrome, do not always ''alert'' the users cause of a self signed certificate. It's very important for us.They will then alert the users that the certificate doesn't match the requested domain name.
2/ Of course, then, if possible, remove the certificate error.
https://forum.netgate.com/topic/137053/how-to-restrict-custom-websites-with-pfblockerng-devel/5
-
Hi, just wondering.
Does pfblockerNG have the option to setup ACL and say, this IP's alias from my LAN can have this blacklist more restricted and have other less restricted?
Like a proxy thing.
I will give a try this package, I use pi-hole but if pfsense do the job, why to have another machine in the network.
Thanks. -
@periko said in pfBlockerNG-devel v2.2.5_18:
Does pfblockerNG have the option to setup ACL and say, this IP's alias from my LAN can have this blacklist more restricted and have other less restricted?
For DNSBL, you can define "views" in the Resolver (Unbound) settings to allow some devices to bypass DNSBL.
https://forum.netgate.com/topic/129365/bypassing-dnsbl-for-specific-ipsFor IP Blocking, you can define the "Advanced In/Outbound" Firewall rule settings at the bottom of each Alias to configure how these Firewall rules apply to your network.
-
@techedge59 said in pfBlockerNG-devel v2.2.5_18:
@grimson Know that... But my goals are:
1/ That all navigators in the lan, and especially Chrome, do not always ''alert'' the users cause of a self signed certificate. It's very important for us.
2/ Of course, then, if possible, remove the certificate error.DNSBL is not going to MITM these blocked domain and serve a false certificate. See the link as indicated by @Grimson, by setting DNSBL Logging as disabled for these particular domains.
-
Wasn't sure if you wanted feedback here or on the original thread. Anyway. One thing to note. I've been using the CARP feature. It's been working fine, the best I can see EXCEPT one blaring issue. "Failing over" to the 2nd node is fine, but when the main node takes over again and is 'master', the Carp Interface for pfB (LAN@1, 10.10.10.1) is still master on the backup node. All other connections fail back to the main node as they are supposed to but the pfB one does not. The quick work around is to disable carp on the 2nd node for a moment, then turn it back on. That forces the interface to switch back to the main node. It seems the pfB Carp interface requires a true 'disconnection' to trigger the switch. It will not auto-switch back to the main node on it's own. Not the end of the world. I can deal with it for now, but something you may want to look into for the next version. Thanks for all the hard work!
-
@bbcan177 If I have multiple Vlans configured and I want different rules for different Vlans, How do I do it? How do I create aliases using DNS blacklist atleast via pfblockerNG?
