IP logs are not being created/populated
-
Yes, I see current logs. And there I also find current logs that should actually be displayed in the pfBlockerNG-"Reports" tab. But this part remains empty since the update to 2.6-RC.
-
What might explain what you see : pfBlockerNG-devel stayed the same.
But if the log format changed - Although I doubt this, the "pfBlockerNG firewall filter service" :fails to work correctly.
Are there nowhere logs about this ??Anyway, if this is an issue, it will get solved right after 2.6 is released.
I'll give 2.6 pre release a go this weekend.From what I make of it, the "pfBlockerNG firewall filter service" parses /var/log/firewall.log, and if the log line number matches a pfBlockerNG rule (with pfBlockNG-devel) alias, it copies the line into its own IP log file for "Report"ing purposes.
Example :
A log line in my Firewall log file :
<134>1 2022-02-10T17:00:10.858798+01:00 pfsense.brit-hotel-fumel.net filterlog 33572 - - 117,,,1770004471,em1,match,block,in,4,0x0,,64,16915,0,none,17,udp,71,192.168.1.32,8.8.8.8,39875,53,51
1770004471 is the firewall rue number.
According to the set of rules (here : /tmp/rules.debug) I know that :
block return log quick on { em1 ovpns1 } inet from any to $pfB_DoH_IP_v4 tracker 1770004471 label "USER_RULE: pfB_DoH_IP_v4 auto rule"
So this checks out.
Check if your pfBlockerNG (floating) firewall rules are in place.
Do they hit any traffic ( packet counters grow !) ?
Inspect all the pfB aliases : they exist and contain IP's ? Be careful with huge aliases, as they will bring pf to its knees. -
- pfb_filter service is up and running
- I cannot find any logs, regarding this issue
Here an example of an log, that I would expect to be shown in the pfblockerng "Reports" tab.
Feb 10 15:58:52 fw01 filterlog[64054]: 191,,,1611675680,pppoe0,match,block,in,4,0x0,,244,63947,0,none,6,tcp,40,89.248.193.120,10.10.1.3,45422,22000,0,S,3657204523,,1024,,
Here the matching rule (from /tmp/rules.debug)
block in log quick on $WAN reply-to ( pppoe0 62.155.242.150 ) inet proto { tcp udp } from ! $pfB_Europe_v4 to any port $open_WAN_Ports ridentifier 1611675680 label "USER_RULE: pfBlocker geoIP (Europe v4)"
Traffic counter for this rule are increasing.
-
I just noticed that our rules are different:
block return log quick on { em1 ovpns1 } inet from any to $pfB_DoH_IP_v4 tracker 1770004471 label "USER_RULE: pfB_DoH_IP_v4 auto rule"
block in log quick on $WAN reply-to ( pppoe0 62.155.242.150 ) inet proto { tcp udp } from ! $pfB_Europe_v4 to any port $open_WAN_Ports ridentifier 1611675680 label "USER_RULE: pfBlocker geoIP (Europe v4)"
For example, your rule uses "tracker" in front of the rule number, in my example it says "ridentifier".
Maybe that´s the issue...
-
There is a fix here:
https://www.reddit.com/r/pfBlockerNG/comments/sk9txi/ip_block_logging_not_working_pfsense_260rc/Will get this into the next release.
-
Thx!
-
And the fix is working, thx! :)
-
-
-
-
-
-
-
-
I've tried running the command and rebooting the pfsense and it still doesn't log anything for the IP's
22.05-DEVELOPMENT (amd64)
built on Thu Mar 03 06:18:46 UTC 2022
FreeBSD 12.3-STABLE
pfblockerng-Devel 3.1.0_1 -
-
-
-
-
-
-
-
If it helps anyone else, I just did 2 pfSense clean load upgrades from 2.5.x to 2.6. After installation the version of pfblockerNG was version 2.1.4_27. pfblockerNG logging did not work on either installation until I uninstalled pfblockerNG and reinstalled. After the reinstall it works great again!
Awesome Package!
-
@bbcan177 said in IP logs are not being created/populated:
https://www.reddit.com/r/pfBlockerNG/comments/sk9txi/ip_block_logging_not_working_pfsense_260rc/
Hello,
Old thread, I know...
I'm trying to apply this patch in the 'patch manager' package and I cant seem to get it to work.curl -o /usr/local/pkg/pfblockerng/pfblockerng.inc "https://gist.githubusercontent.com/BBcan177/7cb8635199446866d511b97166d65296/raw/"
Not sure what I am doing wrong, but I paste the above url in the URL/Commit ID box and there is nothing to fetch.
Then if it paste the above command in the CLI, I get the following error:
PHP Response
Line 1 appears to have generated an error, and has been highlighted. The full response is below.
Note that the line number in the full PHP response will be 6 lines too large. Nested code and eval() errors may incorrectly point to "line 1". -
What is the source of this info ?
Last minute patches could be obtained directly from the source code tree that BB uses to write pfBlocker. These were not pages, you just get the entire file, like /usr/local/pkg/pfblockerng/pfblockerng.inc in this case.Files you curl down to your pfSense are not files to be handled with the pfSense patch manager.
Also, BBcan has to give you access to his https://gist.githubusercontent.com/BBcan177/ on his side.
This : pfBlockerNG-devel 3.1.0_4 is the latest version.
There is a patch I found in redmine : https://redmine.pfsense.org/issues/13154
Here it is
diff --git a/net/usr/local/pkg/pfblockerng/pfblockerng.inc b/net/usr/local/pkg/pfblockerng/pfblockerng.inc index 7fa8c1d2f8bf..2abbef30578b 100644 --- a/net/usr/local/pkg/pfblockerng/pfblockerng.inc +++ b/net/usr/local/pkg/pfblockerng/pfblockerng.inc @@ -4136,7 +4136,7 @@ function pfb_filterrules() { foreach ($results as $result) { if (substr($result, 0, 1) == '@') { - $r = explode(')', $result, 2); + $r = explode(' ', $result, 2); // pfSense > v2.6 uses an 'ridentifier' string if (strpos($result, 'ridentifier') != FALSE) {
but please, don't copy from here (I could have added an exploit ^^), copy from redmine.
-
@gertjan
Thanks for the info!Yeah, I was looking at an old Reddit post which talked about this error and a possible fix. I'm not too keen on typing random stuff in the CLI, so I'll just wait until the real fix is implemented in 3.1.0_5 or 22.09.
The actual bug is not that bad; I've confirmed pfB is blocking/rejecting the IPs in my block list, it's just not logging them...
-
It is odd that this problem still exists for so long now. Sure, it is just an Package but it is the most important one in my book.
-
@bob-dig said in IP logs are not being created/populated:
It is odd that this problem still exists for so long now. Sure, it is just an Package but it is the most important one in my book.
Yeah, @BBcan177 is likely a busy gentleman, but I’m sure a new build will surface eventually.
But pfBlockerNG is much more than “just a package”. I’ll bet you pfBlockerNG is BY FAR the most used package on pfSense. In fact I’d highly recommend Netgate to find the currency needed to purchase the talents of bbcan177 and the pfBlockerNG name, and start including it as a bulitin feature of pfsense. With the same development/maintenance and continuity as pfSense itself.
Without pfBlockerNG, pfSense would be a much much less relevant product.