3.1.0_6 UPDATE
-
@cloudified Same here. As usual, had to manually restart unbound
-
@lohphat said in 3.1.0_6 UPDATE:
@cloudified Same here. As usual, had to manually restart unbound
Same here. This is only my 2nd time upgrading pfBlocker and I guess that's expected behavior.
-
@bbcan177 Is 3.1.0_7 out for +22.05?
-
@jmv43-0 It is, which is why I just posted that. I noticed it as an available upgrade in Package Manager on my 6100 running 22.05+. Plus he already said it would be coming out this week.
-
pfBlocker-NG 3.1.0_7 and acme 0.7.3 as today they are available for 22.05 I updated in time and all is fine since
the update. Look at the numbers now; -
@cloudified said in 3.1.0_6 UPDATE:
I guess that's expected behavior
More or less...I seem to recall a post from BBCan177 a while back, saying it was a bug in pfSense's package system, so he can't fix it.
-
3.1.0_7. everything is fine, but Old rules are not deleted on widget
-
@turker said in 3.1.0_6 UPDATE:
3.1.0_7. everything is fine, but Old rules are not deleted on widget
@turker Do a force reload and restart the pfBlocker services.
-
@cloudified
i do Force reload pfBlocker services and restarted, pfsense restarted. Nothing changed. -
@turker are you getting any table memory errors? That might indicate that you need to increase your Firewall Maximum Table Entries in the System / Advanced / Firewall & NAT section. I had to increase mine from 400,000 to 1,000,000 to account for all of the pfBlocker lists I have configured.
-
@cloudified
@turkerDid you manually create firewall rules for those aliases or did it create them automatically? Check your firewall rules and see if those aliases still appear in your firewall rules, if they do, delete those firewall rules.
I've seen cases where I created rules with aliases in pfBlocker but didn't delete them and they would still show up in that table, like you are showing.
-
@jdeloach said in 3.1.0_6 UPDATE:
@cloudified
Did you manually create firewall rules for those aliases or did it create them automatically? Check your firewall rules and see if those aliases still appear in your firewall rules, if they do, delete those firewall rules.
I've seen cases where I created rules with aliases in pfBlocker but didn't delete them and they would still show up in that table, like you are showing.
I think you meant to reply to @turker.
-
@cloudified
Yeah, I just saw that and edited my post. Thanks! -
-
@cloudified said in 3.1.0_6 UPDATE:
@turker are you getting any table memory errors? That might indicate that you need to increase your Firewall Maximum Table Entries in the System / Advanced / Firewall & NAT section. I had to increase mine from 400,000 to 1,000,000 to account for all of the pfBlocker lists I have configured.
One other comment, there has been a lot of discussion in numerous posts on this forum as to what value, Firewall Maximum Table Entries should be. They are several cases where folks have used anywhere from 400,000 to 10,000,000. I think most consider 2,000,000 to be a good number to use but it seems to vary depending on each users system, memory and which/how many lists folks choose to use. I just checked my system and I have 4,000,000, why, I don't know, it works so I don't plan to change it.
As far as the default value, that bug/error has been around since day one with this package, even before BBcan177, took over as the maintainer, if remember correctly. I think the pfSense/Netgate/maintainer GODS think it is a low priority fix and have ignored it all these years.
-
@cloudified said in 3.1.0_6 UPDATE:
@turker are you getting any table memory errors?
No. -
The problem may be caused by me.
Rule 5 seems to be assigned to the interface but i have 4 interfaces. I deleted one.
Looks like it was assigned to the deleted interface.
-
@jdeloach said in 3.1.0_6 UPDATE:
@cloudified said in 3.1.0_6 UPDATE:
@turker are you getting any table memory errors? That might indicate that you need to increase your Firewall Maximum Table Entries in the System / Advanced / Firewall & NAT section. I had to increase mine from 400,000 to 1,000,000 to account for all of the pfBlocker lists I have configured.
One other comment, there has been a lot of discussion in numerous posts on this forum as to what value, Firewall Maximum Table Entries should be. They are several cases where folks have used anywhere from 400,000 to 10,000,000. I think most consider 2,000,000 to be a good number to use but it seems to vary depending on each users system, memory and which/how many lists folks choose to use. I just checked my system and I have 4,000,000, why, I don't know, it works so I don't plan to change it.
As far as the default value, that bug/error has been around since day one with this package, even before BBcan177, took over as the maintainer, if remember correctly. I think the pfSense/Netgate/maintainer GODS think it is a low priority fix and have ignored it all these years.
In my case I was getting the error because the default size of 400,000 on my 6100 was not enough for the lists I have configured. The error went away after increasing it to 1,000,000.
-
@cloudified said in 3.1.0_6 UPDATE:
the default size of 400,000 on my 6100 was not enough for the lists I have configured
A few years ago I documented that BBcan177 posted to double the default, with a minimum of 2 million. It of course depends on the number of entries used and the RAM installed. In theory someone could just use one small list and not need very many at all. Others "block the world" and use quite a lot.
It would be nice if the package checked that setting upon install and showed a warning somewhere.
@jdeloach said in 3.1.0_6 UPDATE:
As far as the default value, that bug/error has been around since day one with this package
The Firewall Maximum Table Entries setting is a pfSense setting...it has nothing to do with the pfBlocker package. Other than, pfB creates table entries. I don't recall when the bug showed up but I noticed it a year or two ago, whenever I made the report. If you think it's been longer I'll just believe you. :) I didn't have any old routers to check...we keep our clients pretty current.
-
@steveits Totally agree. It was be really nice if pfBlocker checked your current table size setting when a list update goes above the threshold.