pfSense » pfSense Packages

pfBlockerNG page shows:

When manually creating 'Alias' type firewall rules; Prefix the Firewall rule Description with pfb_ This will ensure that that Dashboard widget reports those statistics correctly.

I saw this bug on 22.05-Devel and now on 22.05-Beta. The rules are working, but are not logged.

There seems to have been a change in the pfctl -vvsr output.

The patch below seems to fix the issue, but would be good if it was tested in several different versions to ensure its working for all versions.

File: /usr/local/pkg/pfblockerng/pfblockerng.inc

Line: 4139

From:
$r = explode(')', $result, 2);

To:
$r = explode(' ', $result, 2);

Save the file and restart the pfb_filter Service for the changes to take effect.

Tested change on 22.05 RC with pfBlockerNG-devel 3.1.0_4; floating block rule on tagged traffic with description pfb_blocklist. Block shows in firewall filter log, but not in pfB's reports tab.

The patch works for me on LAN and WAN rules on 22.05 RC using pfBlockerNG-devel 3.1.0_4. I don't have floating rules to test those, but blocked IP's on LAN and WAN are now logging for me on the dashboard, the Reports-->Alerts tab, and in Reports-->IP Blocks Stats.

Marcos Mendoza wrote in #note-4:

Tested change on 22.05 RC with pfBlockerNG-devel 3.1.0_4; floating block rule on tagged traffic with description pfb_blocklist. Block shows in firewall filter log, but not in pfB's reports tab.

Can you run a pfctl -vvsr and post the Rule indicated above?

@256 block drop in log quick on ixv5 inet from any to <h_blocklist:19320> label "USER_RULE: pfb_blocklist" label "id:1648438642" ridentifier 1648438642 ! tagged passlist

Marcos Mendoza wrote in #note-7:

@256 block drop in log quick on ixv5 inet from any to <h_blocklist:19320> label "USER_RULE: pfb_blocklist" label "id:1648438642" ridentifier 1648438642 ! tagged passlist

The Aliastable in your rule is "h_blocklist" while pfBlockerNG creates aliastables starting with "pfB_". So it doesn't see this rule as a pfBlockerNG rule.

Code here:
https://github.com/pfsense/FreeBSD-ports/blob/devel/net/pfSense-pkg-pfBlockerNG-devel/files/usr/local/pkg/pfblockerng/pfblockerng.inc#L4150

Is there a particular reason for that? I'm using a custom alias to keep rule management easier, and to avoid filter loading issues when alias tables are empty (e.g. when restoring the config after reinstall).

BBcan177 . wrote in #note-3:

There seems to have been a change in the pfctl -vvsr output.

The patch below seems to fix the issue, but would be good if it was tested in several different versions to ensure its working for all versions.

File: /usr/local/pkg/pfblockerng/pfblockerng.inc

Line: 4139

From:
$r = explode(')', $result, 2);

To:
$r = explode(' ', $result, 2);

Save the file and restart the pfb_filter Service for the changes to take effect.

This fixed the logging in "IP Block Stats" for me.
After moving from 22.01 to 22.05 RC the logging didn't work.
But it's okay now with the hot fix. Thanks :)

Even with changing the rule to use the pfBlockerNG aliases directly, the issue persists - that is I'm not seeing any IP block stats in the reports tab. Here's the rule:

@261 block drop in log quick on ixv5 inet from any to <pfB_Top_v4:11696> label "USER_RULE: pfb_blocklist" label "id:1655164364" ridentifier 1655164364 ! tagged passlist

The rule identifier matches what is shown in the filter log blocking the IP address in the pfB_Top_v4 table.

I just tested and your patch also works on the latest 2.7.0-DEVELOPMENT.

This fix doesn't work for me, I still can't get any logging of IP blocks, even though the dashboard counter shows it and I can see the blocks in the firewall log.

pfsense+ V 22.05
pfblockerNG-devel V 3.1.0_4

same for me
using
pfsense+ V22.05
pfblockerNG-devel V3.1.0_4

basic setup using wizard.

manually edit the pfblockerng.inc file, restarted pfb_filter services, still nog information in reports IP Blocked stats
dashboard shows IP & DNSBL active > 300 blocks on IP.

when using status -> system logs -> firewall -> normal view is see blocked actions with "pfB_PRI1_v4 auto rule (1770010313)" as rule

found the issue why it was not working for me. the patch above, it was not "clear" for me it had to be ' <space> ' , i changed it to '' (no space)
after reading 13154 , high cpu , i noticed it was " " not empty string :-(

now IP block stats is working , but permit and match stats stay empty....
i have all GEOIP list in match both action running, but no matching stats yet after 30 minutes .

luc Willems wrote in #note-15:

found the issue why it was not working for me. the patch above, it was not "clear" for me it had to be ' <space> ' , i changed it to '' (no space)
after reading 13154 , high cpu , i noticed it was " " not empty string :-(

now IP block stats is working , but permit and match stats stay empty....
i have all GEOIP list in match both action running, but no matching stats yet after 30 minutes .

Thank you Luc, I was making the same mistake, it is now working for me.

Thx Marcos tested V1 patch an V2 and they do their jobs thanks a lot ==> version tested pfBlockerNG-devel, version 3.1.0_4 and tested on pfsense version 22.05 and 22.09

FWIW, I believe that this issue is still present in the just released pfBlockerNG-devel 3.1.0_6.

Same fix needed as before:

*** pfblockerng.inc.org    2022-10-10 14:35:41.159055000 -0700
--- pfblockerng.inc    2022-10-10 14:34:26.122428000 -0700
*************** function pfb_filterrules() {
*** 4136,4142 ****
          foreach ($results as $result) {
              if (substr($result, 0, 1) == '@') {

!                 $r = explode(')', $result, 2);

                  // pfSense > v2.6 uses an 'ridentifier' string
                  if (strpos($result, 'ridentifier') != FALSE) {
--- 4136,4142 ----
          foreach ($results as $result) {
              if (substr($result, 0, 1) == '@') {

!                 $r = explode(' ', $result, 2);

                  // pfSense > v2.6 uses an 'ridentifier' string
                  if (strpos($result, 'ridentifier') != FALSE) {

I can confirm this also. Problem still exists in 3.1.0_6

Same here, problem still exists.

Yep, same problem, same fix still works.

I can also confirm this issue exists in 3.1.0_6, the same line has to be changed.