New pfblockerNG install Database Sanity check Failed

[madmaxpr]

Still seeing this on the newest 2.8 release, just updated today.

[tinfoilmatt]

Try performing the process outlined under Firewall / pfBlockerNG / General / Keep Settings:

Note: To clear all downloaded lists, uncheck these two checkboxes and 'Save'. Re-check both boxes and run a 'Force Update|Reload'

[marchand.guy]

@tinfoilmatt I don't see "2 settings" just one.

[marchand.guy]

@marchand-guy And no, it did not fix the error.

[tinfoilmatt]

@marchand-guy said in New pfblockerNG install Database Sanity check Failed:

@tinfoilmatt I don't see "2 settings" just one.

Firewall / pfBlockerNG / General / pfBlockerNG "Enable" checkbox

and

Firewall / pfBlockerNG / General / Keep Settings "Enable" checkbox

Uncheck both checkboxes (to disable each), click "Save", re-check both checkboxes (to re-enable each), click "Save" again—and finally run Force Update | Reload All.

You might consider starting a new thead unless you have the same exact issue as OP (i.e., a failed "Database Sanity check").

[marchand.guy]

@tinfoilmatt Same exact problem. Thank you.

[marchand.guy]

@tinfoilmatt Same result as OP after your suggestion:
Database Sanity check [ FAILED ] ** These two counts should match! **

Masterfile Count [ 81362 ]
Deny folder Count [ 81361 ]

[tinfoilmatt]

@marchand-guy What do you see in the error.log file? Anything else relevant printed to the pfblockerng.log file?

[marchand.guy]

@tinfoilmatt Nothing relevant in pfblockerng.log, aside from the reported error.
What I found is that the masterfile has indeed 81362 entries, but the deny files amount to 81364. Comparing the 2, I see that the deny files have 127.1.7.7 listed 3 times instead of 1 in the masterfile. So somehow the code is mishandling the duplicates between the 2 files.

[BBcan177]

@marchand-guy

The code should handle the blank file ip placeholder.

Starts at Line 1232 to 1289
https://github.com/pfsense/FreeBSD-ports/blob/0acb5dc2ad321340aafdf282a20f9c02762d49d5/net/pfSense-pkg-pfBlockerNG-devel/files/usr/local/pkg/pfblockerng/pfblockerng.sh#L1232

Maybe there is some corner case the code is missing?

[marchand.guy]

@BBcan177 I am not a programmer. But a simple "sort -u" of the deny files entries bring them back to 81362. Just saying...

[tinfoilmatt]

@marchand-guy Did you compare your pfblocker.sh to the appropriate branch version?

What version of pfSense? What version of pfBlockerNG/-devel?

[marchand.guy]

@tinfoilmatt
2.8.0-RELEASE (amd64)
built on Wed May 21 19:12:00 EDT 2025
FreeBSD 15.0-CURRENT

The system is on the latest version.
Version information updated at Sat May 31 15:09:52 EDT

pfBlockerNG net 3.2.8
(yes I tried the -devel version prior to this one. no difference)

[Maltz]

I'm seeing the same off-by-one error on my system. I'm running the same versions as marchand.guy.

What is the impact of this error? Does it prevent any functionality?

[madmaxpr]

@SteveITS Still seeing this error myself but have no further info. It does seem to function, just with the error being shown when it updates/reloads.

[TheXman]

I was experiencing the same issue too.

After comparing /usr/local/pkg/pfblockerng/pfblockerng.sh from 3.2.0 to 3.2.8, there was only 1 line that changed and it happened to be related to this issue. After reverting that line (#1281) back to the way it was in 3.2.0, the "Sanity Check" works as expected.

Here are the lines as they exist in their respective versions.

#Line 1281 in 3.2.0
if [ "${s1} == ${s2}" ]; then

#Line 1281 in 3.2.8
if [ "${s1}" == "${s2}" ]; then

Edit: Corrected my references to pfBlockerNG version numbers. Thanks @Maltz

[Maltz]

@TheXman Wouldn't the 2.7.2 version always evaluate as true, since the string is non-null? It looks like the sanity check was fixed in 2.8.0, exposing some other issue that may have been there all along but was hidden by the broken sanity check.

(Edit: I guess the version numbers should be 3.2.0_8 and 3.2.8, respectively, since we're talking about pfBlockerNG and not pfSense itself.)

[marchand.guy]

@Maltz That is an excellent hypothesis!

[marchand.guy]

@marchand-guy Verified hypothesis. The code always reported true before 3.2.8.
Good catch

[tinfoilmatt]

Looks like dev (@BBcan177) is already reviewing. Good teamwork, y'all.

Responsible commit here. Remark indicates it was a cleanup commit. I don't have the coding skills to say for sure, but this pfblocker.php update and this pfblocker_alerts.php update look odd for some reason, in addition to whatever the pfblockerng.sh L1281 fix exposed.

@marcosm