PfBlockerNG
-
I used the patch method to install pfBlockerNG, and it was working well on two machines until a reboot. After a reboot the country block lists in /var/db/aliastables/ are all empty but for a single entry of 1.1.1.1.
Forcing an update does not fetch the correct files, and no blocking is taking place.
-
I used the patch method to install pfBlockerNG, and it was working well on two machines until a reboot.
Is this a Nano install where the /var folder is getting deleted on reboot?
This is a question I have asked the Devs to find a solution for… As these files should be stored in the /var folder. The previous pfBlocker package used to store the files in the /usr/local folder. This issue is only limited to Nano and Ramdisk type installs.
Run the following shell command to Re-Download the Maxmind Database, and restore the Country code files in the /var folder.
php /usr/local/www/pfblockerng/pfblockerng.php dc
Following that, execute a "Force Update"
-
Is this a Nano install where the /var folder is getting deleted on reboot?
I guess so.
You may need a conf mount rw to backup data on package save.
I found a long time ago a guide to run nanobsd on virtual machine. This way will be easier to debug cf installs.
-
You may need a conf mount rw to backup data on package save.
I found a long time ago a guide to run nanobsd on virtual machine. This way will be easier to debug cf installs.
Yes, I have a similar doc on that running a Nano in a VM. In this instance, there is nothing to debug.. The /var/db folder which contains the Maxmind Country files get wiped on reboot. I can make a hack way around it in the code which probably is not the best.
This is a question I have posed to the Devs, but I am waiting on feedback for the best approach. I do not want to save these files to the /usr/local folder.
Maybe could put it in the PBI Share Folder?
-
Yes indeed, it is a nano install. Thank you for the fix!
-
The /var/db folder which contains the Maxmind Country files get wiped on reboot. I can make a hack way around it in the code which probably is not the best.
This is a question I have posed to the Devs, but I am waiting on feedback for the best approach. I do not want to save these files to the /usr/local folder.
Maybe could put it in the PBI Share Folder?The /var/db thing is rather unfortunate, not just b/c it's volatile but also since the directory is pretty huge. Takes over 1/3 of the default /var ramdisk.
-
pfBlockerNG needs the Maxmind database country codes otherwise most of the functions will not work.
-
pfBlockerNG needs the Maxmind database country codes otherwise most of the functions will not work.
Hmmm, yeah… and the point being? It's already there.
-
The point being if we added a "disable country codes" mode then you would free up the memory.
This can be a solution for low-memory devices, but then you would miss out all the benefits like reputation, country blocking etc. -
And what would be the point of doing that in a countryblock package?
-
The point being if we added a "disable country codes" mode then you would free up the memory.
Cannot see anyone suggesting something similar anywhere. All that's being discussed here is moving the files to a better place.
-
The /var/db thing is rather unfortunate, not just b/c it's volatile but also since the directory is pretty huge. Takes over 1/3 of the default /var ramdisk.
Thats why I suggested the option to disable country blocking as a whole, only as an option…
And what would be the point of doing that in a countryblock package?
pfBlockerNG is much more than just a countryblock package.
I think most of the users use pfBlockerNG as an ip-blocklist and use the countrycodes only for reputation. -
Well. I can tell you differently…
I use them for blocking as well since I dont want anything to do with the countries I block....and my customers dont have any business there as well.
So I dont get the traffic on my servers and I can sleep fairly safe at night :D
-
Meanwhile, you can use Shellcmd package and run this as shellcmd on nanobsd boxes:
/usr/local/bin/php /usr/local/www/pfblockerng/pfblockerng.php dcto get the blocklists back on reboot.
-
I will be submitting a Pull Request for the following :
-
MaxMind files will be saved to the PBI folder which will make them persist after reboot. (for Nano / Ramdisk installs)
-
MaxMind archive files in /var/db will be purged after installation to free up some memory.
-
Add MaxMind "Anonymous Proxy and Satellite Providers".
I think Digdug is suggesting to have the option of not installing the MaxMind database to free up some more space. I have an option in the General tab to skip downloading future MaxMind updates, but it doesn't delete the existing installed Files. I could create a function to clear them out but I also need to re-install the files if the user Un-checks this option.
Also note that "Reputation" and the Alerts tab require the use of the GeoIP.dat and GeoIPv6.dat to function.
-
-
See:
https://forum.pfsense.org/index.php?topic=86212.msg481358#msg481358Make sure you read this entire thread.
In that thread it mentions 'look at the screenshot' a number of times, but I don't see a screenshot in the thread anywhere. I make the patch, it says it can be applied, but not reverted, so was going to double check settings to make sure I didn't do something stupid ion the patch definition…
-
1/ The screenshot shows just fine, fix your browser.
2/ You obviously cannot revert patches that have not been applied. -
Thanks. You are right, the screenshot was there. For some reason it took a LONG time to load though (I was on that page for >3 minutes before the screenshot actually appeared…).
And, yeah, I should have realized it couldn't revert.
I have it all installed, configured, and working now. Thanks all for the guidance.
Thanks!
-
The pull request needs to be merged by pfsense team before you can use it without any hacks.
Mostly out of curiosity, what does this mean for where this package is in the release process? That is, does the pfsense team do some testing before they merge it? Or do they just do some sort of minimal sanity check through the code?
-
If I understand correctly, they do an in-depth review of the code. This being a "New" package with a large code base it can take a while. I believe it is in that process now. It is in the pfSense package repository but is waiting for this process to be completed. The "patch", I hate the word "Hack", just allows you to bypass the "compatibility check" to download the package from the pfSense repository before it has gone through this process. It is "Use at your own risk" at the moment. The review process is a good thing. We just have to be patient.
The pull request needs to be merged by pfsense team before you can use it without any hacks.
Mostly out of curiosity, what does this mean for where this package is in the release process? That is, does the pfsense team do some testing before they merge it? Or do they just do some sort of minimal sanity check through the code?
