state counters, firewall rules resetting?

stephenw10

Yeah that doesn't apply in 23.01. set keepcounters is present in the pf ruleset file by default.

nimrod

@stephenw10 said in state counters, firewall rules resetting?:

Yeah that doesn't apply in 23.01. set keepcounters is present in the pf ruleset file by default.

Just to make sure we are on the same page here. If i apply that patch on CE version does that mean set keepcounters is getting set or removed?

johnpoz

@stephenw10 well they are resetting that is for sure

And I watched some roku, and it did show traffic and now this morning its back to 0/0

Hmmm?

Gertjan

@johnpoz

I'm following these counters since yesterday.

Curious to know when counters get reset.
Something like : you modified a rule, something you obviously didn't do.
Have you rules that are scheduled ?
Counter reset means to me : "new" rules so also states are reset ( ? )

johnpoz

@gertjan yeah no changes to rules since yesterday that is for sure.. And I don't have any rules on a schedule..

The only thing that is scheduled is my aliases in pfblocker - those update, but I don't have any sort of auto rules even enabled in pfblocker, only the native aliases..

If I look in changes

03. 3/6/23 09:48:16     v22.8   admin@192.168.9.100 (Local Database)
    Firewall: NAT: Outbound - reordered outbound mappings.

02. 3/6/23 15:00:16     v22.8   (system)
    pfBlockerNG: saving DNSBL changes

01. 3/7/23 15:00:16     v22.8   (system)
    pfBlockerNG: saving DNSBL changes

That is an odd comment on the pfblocker change - since I don't even have DNSBL enabled. But do have it set to update my aliases every 6 hours..

But clearly that is on a schedule..

If I look at my crons - I would assume that listing in the config changes is the bottom one

But why should it reset the counters?

edit: well I just manually kicked off a pfblocker update and it shows in the config log

01. 3/9/23 04:59:54     v22.8   (system)
    pfBlockerNG: saving DNSBL changes

But my counters didn't reset, sill show the same amount of traffic on my lan rule, as I did before running it. So its prob not that doing it... hmmm?

stephenw10

@johnpoz said in state counters, firewall rules resetting?:

@stephenw10 well they are resetting that is for sure

Indeed, they sure seem to be.... I can't trigger it to reset either. Yet.

Jarhead

@stephenw10 Just to throw my hat in, checked yesterday and had over a gig on the LAN, today 800M.

bigsy

@johnpoz Do you have the patch for redmine #14016 applied?

I had a problem on 23.01 with pfBlocker IP counters resetting overnight until I applied this. I didn't notice the firewall counters. Something in the default cron jobs must have been resetting it?

jdeloach

This post is deleted!

tman222

@bigsy said in state counters, firewall rules resetting?:

@johnpoz Do you have the patch for redmine #14016 applied?

I had a problem on 23.01 with pfBlocker IP counters resetting overnight until I applied this. I didn't notice the firewall counters. Something in the default cron jobs must have been resetting it?

Thanks @bigsy for calling out this patch. I have been running into the same issue (pfBlockerNG IP counters resetting overnight) and then noticed similar to @johnpoz that my traffic counters didn't make sense. Applied the patch and will monitor to see if that has hopefully fixed it.

Relevant thread:
https://forum.netgate.com/topic/178107/23-01-periodic-scripts-have-been-re-enabled-and-are-broken/5

johnpoz

@bigsy I think you might of found it, I do have 2 patches installed for state issues

https://github.com/pfsense/pfsense/commit/d9fa4584e3fb63d6051e9f1db7655f931cb1be19.patch

and one I manually applied

diff --git a/blah/usr/local/www/rrd_fetch_json.php b/blah/usr/local/www/rrd_fetch_json.php
index df0401f96e89..4d7574819ac9 100644
--- a/blah/usr/local/www/rrd_fetch_json.php
+++ b/blah/usr/local/www/rrd_fetch_json.php
@@ -226,7 +226,8 @@ foreach ($side as $settings) {
                                $ds = "state changes";
                                break;
                        case "pfnat":
-                               $ignore = true;
+                               $unit_acronym = "";
+                               $ds = "NAT states";
                                break;
                        case "inpass":
                                $ninetyfifth = true;

Looking into the details now.

edit: ok applied ff715efce5e6c65b3d49dc2da7e1bdc437ecbf12 lets see if resets tonight or next couple of days.

stephenw10

Same here. Let's see....

Gertjan

@johnpoz said in state counters, firewall rules resetting?:

edit: ok applied ff715efce5e6c65b3d49dc2da7e1bdc437ecbf12

I had that one already active.
My counter are still good / plausible.

johnpoz

@gertjan nope reset...

WTF???

bigsy

@johnpoz Did you reboot or trigger a rewrite of the cron config after applying the patch per this link?

johnpoz

@bigsy valid point - I did not reboot.. That is the only way to redo the crons? Got to be a better way ;)

ok - I went in and did a save on couple crons, without changing anything... This should of kicked them in, but no I didn't do that after apply the patch. Did that now.. Lets see..

Gertjan

@johnpoz

You have (default I guess) :

I have

Which says : ones a day, at minute 15.
as I'm not trying to update my single DNSBL (ADs_basic) that often - it's actually set to 'Weekly'.

Which means my pfBlockerng tries to actually update my single list ones a week.

I'll do a force update .... nothing changed.

Btw : take note : I have no IP feeds so no pfBlockerng firewall rules what so ever. My floating pane is empty.

johnpoz

@gertjan said in state counters, firewall rules resetting?:

Which says : ones a day, at minute 15.

No not minute - that is hour.

15 is 3pm for non 24 hour clock people ;)

Something lost in translation with the cron setting in pfblocker it seems..

Gertjan

@johnpoz said in state counters, firewall rules resetting?:

non 24 hour clock people ;)

By any chance, are these flat-earthers related ?
I was told a day has 24 hours.

Anyway :

What I make of it : "15 minutes after midnight".
If it's something else : fine to me

bingo600

I just applied the patch

This is my Crontab after applying the patch , but nothing else

Pre-Reroot

/root: vi /etc/crontab

# /etc/crontab - root's crontab for FreeBSD
#
# $FreeBSD$
#
SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
#
15      4       *       *       6       root    periodic weekly
30      5       1       *       *       root    periodic monthly
#
# Adjust the time zone if the CMOS clock keeps local time, as opposed to
#
# pfSense specific crontab entries
# Created: March 10, 2023, 7:06 am
#

1,31    0-5     *       *       *       root    /usr/bin/nice -n20 adjkerntz -a
1       3       1       *       *       root    /usr/bin/nice -n20 /etc/rc.update_bogons.sh
1       1       *       *       *       root    /usr/bin/nice -n20 /etc/rc.dyndns.update
*/60    *       *       *       *       root    /usr/bin/nice -n20 /usr/local/sbin/expiretable -v -t 3600 virusprot
30      12      *       *       *       root    /usr/bin/nice -n20 /etc/rc.update_urltables
1       0       *       *       *       root    /usr/bin/nice -n20 /etc/rc.update_pkg_metadata
*/1     *       *       *       *       root    /usr/sbin/newsyslog
1       3       *       *       *       root    /etc/rc.periodic daily
15      4       *       *       6       root    /etc/rc.periodic weekly
30      5       1       *       *       root    /etc/rc.periodic monthly
*/1     *       *       *       *       root    /usr/local/pkg/servicewatchdog_cron.php
#
# If possible do not add items to this file manually.
# If done so, this file must be terminated with a blank line (e.g. new line)
#

:q!

Same contents after restarting Cron aka no change in the jobs

/root: /etc/rc.d/cron restart
Stopping cron.
Waiting for PIDS: 31184.

I did a "Reroot" , and didn't even loose my webradio stream

Post Reroot
#
# pfSense specific crontab entries
# Created: March 10, 2023, 11:59 am
#
SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin

1,31    0-5     *       *       *       root    /usr/bin/nice -n20 adjkerntz -a
1       3       1       *       *       root    /usr/bin/nice -n20 /etc/rc.update_bogons.sh
1       1       *       *       *       root    /usr/bin/nice -n20 /etc/rc.dyndns.update
*/60    *       *       *       *       root    /usr/bin/nice -n20 /usr/local/sbin/expiretable -v -t 3600 virusprot
30      12      *       *       *       root    /usr/bin/nice -n20 /etc/rc.update_urltables
1       0       *       *       *       root    /usr/bin/nice -n20 /etc/rc.update_pkg_metadata
*/1     *       *       *       *       root    /usr/sbin/newsyslog
1       3       *       *       *       root    /etc/rc.periodic daily
15      4       *       *       6       root    /etc/rc.periodic weekly
30      5       1       *       *       root    /etc/rc.periodic monthly
*/1     *       *       *       *       root    /usr/local/pkg/servicewatchdog_cron.php
#
# DO NOT EDIT THIS FILE MANUALLY!
# Use the cron package or create files in /etc/cron.d/.
#

That cleaned up the crontab file

Seems like this is taken out by the patch

#
15      4       *       *       6       root    periodic weekly
30      5       1       *       *       root    periodic monthly
#
# Adjust the time zone if the CMOS clock keeps local time, as opposed to
#

/Bingo