2.1.5 –> 2.2, pfblocker extremely slow loading of rules on boot.
-
Hello all:
I just upgraded a couple of boxes both running nanobsd 64 bit, one Intel Core 2 Duo, and one AMD Sempron.
Both machines stall on reboot at the first "configuring firewall" boot notice. I deactivated pfblocker, and the machines both boot very quickly. With pfblocker activated, the machines take almost 10 minutes to load the rules.
Both boxes booted very quickly when running 2.1.5 and its predecessors.
I uninstalled pfblocker, manually stripped all references to it from config.xml, rebooted, and reinstalled pfblocker, but the slow loading on boot persists.
While not a show stopper, the behavior may be mistaken for a complete machine hang if one is not patient enough to wait it out.
I have another Atom based machine that threw a very strange error with IPSec and spontaneously rebooted. I will detail that issue in another post if I can reproduce it. In the meanwhile the Atom based machine has been replaced by the AMD box mentioned above.
Cheers, and kudos to the developers on job well done. I expect that many of these little quirks will be ironed out in the coming weeks as the new release sees a broader base of hardware.
-
Seeing the same problem here.
-
Known issue, stop wasting your time with this dead package.
-
A replacement would be?….
-
The replacement would be pfBlockerNG – whenever someone decides to stop hiding that from users.
-
Cool.
-
There seems to be an issue with some IBlock lists where the conversion of the range to cidr is crashing php. My package uses a newer function that is not exhibiting this issue.
Disable the IBlock lists one at a time to isolate the bad list. However this could change depending on the ranges being published in the list.
If you are still seeing issues with reboot, try to delete the pfBlocker files in /var/db/aliastables.
-
I will try to figure out which is the bad list, as you describe. In this implementation I am only using the basic country lists, and I have it set to deny incoming traffic from almost all of them.
I'm not clear on what you mean when you say "My package uses a newer function that is not exhibiting this issue." Is this fixed package available anywhere?
There was some discussion of problems with the Range2CIDR function back in 2013. Is the problem I am seeing related? Has the transition to the new PHP system caused a regression?
https://redmine.pfsense.org/issues/2892
-
If you are only using the country blocking features of pfBlocker then those lists do not require conversion as they are already in cidr format.
I would disable pfBlocker. Then confirm if /var/db/aliastables is clear of all pfBlocker files. If not, delete any remaining files.
Then enable pfBlocker and reboot to see if it's still slow.
I have developed a new package called pfBlockerNG which is currently being reviewed by the devs.
-
With pfblocker disabled or uninstalled the machines boot lightning fast. As soon as I re-enable pfblocker it chokes at "Configuring firewall", and there is no progression of periods while it loads rules.
I look forward to your new package making it into distribution!
-
If you are only using the country blocking features of pfBlocker then those lists do not require conversion as they are already in cidr format.
I would disable pfBlocker. Then confirm if /var/db/aliastables is clear of all pfBlocker files. If not, delete any remaining files.
Then enable pfBlocker and reboot to see if it's still slow.
I have developed a new package called pfBlockerNG which is currently being reviewed by the devs.
BBcan177 - Any timeline from the devs on pfBlockerNG making it into the packages? I have been waiting for this to hit mainstream since last year when talking to you. Looks as if it may be the best fix for us PFblocker user folks. Thanks again for your hard work on it.
Ash,
