Project

General

Profile

Actions

Regression #13156

closed

pfBlockerNG IP block stats do not work

Added by Marcos M over 2 years ago. Updated about 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
pfBlockerNG
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Affected Version:
Affected Plus Version:
22.05
Affected Architecture:
All

Description

On 22.01, the filter log rules description includes the rule id in parenthesis. This breaks the IP block tracking for pfBlockerNG-devel.


Files

13156.txt (3.58 KB) 13156.txt Marcos M, 08/30/2022 06:57 PM
13156_2.patch (3.71 KB) 13156_2.patch Marcos M, 09/11/2022 03:57 PM

Related issues

Related to Bug #13154: pfBlocker causing excessive CPU loadResolvedMarcos M

Actions
Actions #1

Updated by Marcos M over 2 years ago

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.

Actions #2

Updated by Glenn Hall over 2 years ago

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

Actions #3

Updated by BBcan177 . over 2 years ago

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.

Actions #4

Updated by Marcos M over 2 years ago

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.

Actions #5

Updated by Glenn Hall over 2 years ago

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.

Actions #6

Updated by BBcan177 . over 2 years ago

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?

Actions #7

Updated by Marcos M over 2 years ago

@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

Actions #8

Updated by BBcan177 . over 2 years ago

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

Actions #9

Updated by Marcos M over 2 years ago

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).

Actions #10

Updated by B. B. over 2 years ago

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 :)

Actions #11

Updated by Marcos M over 2 years ago

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.

Actions #12

Updated by Glenn Hall over 2 years ago

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

Actions #13

Updated by Adrian Hansraj over 2 years ago

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

Actions #14

Updated by luc Willems over 2 years ago

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

Actions #15

Updated by luc Willems over 2 years ago

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 .

Actions #16

Updated by Adrian Hansraj over 2 years ago

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.

Actions #17

Updated by Marcos M about 2 years ago

  • Related to Bug #13154: pfBlocker causing excessive CPU load added
Actions #18

Updated by Marcos M about 2 years ago

  • Status changed from New to Pull Request Review
  • Assignee set to Marcos M

Fix:
https://gitlab.netgate.com/pfSense/FreeBSD-ports/-/merge_requests/261

This also handles cases where a rule uses tags (e.g. #note-11).

Actions #19

Updated by Marcos M about 2 years ago

Here's the patch to test - use the System Patches package and copy/paste the contents of the attached file. Apply the patch then restart the pfb_filter service afterwards.

Actions #20

Updated by Marcos M about 2 years ago

Additional fix:
https://gitlab.netgate.com/pfSense/FreeBSD-ports/-/merge_requests/276

This resolves the IP block stats within the widget not correctly counting rules with multiple interfaces defined (e.g. floating rules). Patch is attached.

Actions #21

Updated by collin Collen about 2 years ago

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

Actions #22

Updated by Denny Page about 2 years ago

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) {

Actions #23

Updated by OpIT GmbH about 2 years ago

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

Actions #24

Updated by Atte Laukkanen about 2 years ago

Same here, problem still exists.

Actions #25

Updated by O E about 2 years ago

Yep, same problem, same fix still works.

Actions #26

Updated by Adrian Hansraj about 2 years ago

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

Actions #27

Updated by Marcos M about 2 years ago

  • Status changed from Pull Request Review to Resolved

Fixes are merged and working:
3.1.0_6 for pfSense CE
3.1.0_7 for pfSense Plus

Actions

Also available in: Atom PDF