block rules not logging
-
@tinfoilmatt nice catch
[25.11-RELEASE][admin@sg4860.home.arpa]/: ps -A | grep syslogd 94189 - SCs 0:02.15 /usr/sbin/syslogd -O rfc3164 -s -c -c -l /var/dhcpd/var/run/log -l /tmp/haproxy_chroot/var/run/log -P /var/run/syslog.pid -f /etc/syslog.conf 95527 - I 0:00.01 syslogd: syslogd.casper (syslogd) 96345 - Is 0:00.00 syslogd: system.net (syslogd) 57942 0 S+ 0:00.00 grep syslogd [25.11-RELEASE][admin@sg4860.home.arpa]/:Really odd - I have no issues..
-
@tinfoilmatt the raw logging plus reboot makes logical sense since it'd restart pflog/filterlog in addition to changing the configuration. I'll do so when there are fewer people in my house :)
-
@tinfoilmatt raw logging+reboot = no go, unfortunately. I'm wondering if there's a good way for me to look at the raw output of pflog - it seems pfSense does something to capture and manage that information using the filterlog process.
As an experiment I set up a syslog server on my home network and directed pfSense to send its output there, and it was able to capture everything pfSense is capturing log-wise, but still nothing from the firewall.
root 27982 0.0 0.1 15000 3776 - Ss Fri01 0:05.84 /usr/local/sbin/filterlog -i pflog0 -p /var/run/filterlog.pidThe filterlog process seems to be the next place to focus troubleshooting, but some googling makes it seem like it's sort of a black box - a simple one, but not one that people seem to have issues with in terms of troubleshooting. Any ideas on where to start looking? If I had to guess, I'd say maybe there was some kind of issue with how it's configured (like trying to parse out the wrong interface's messages or something), rather than a bug causing it to fail.
-
@beatvjiking Fresh install and config restore is your best option. Something is corrupted. Not worth identifying what.
-
@beatvjiking said in block rules not logging:
I'd say maybe there was some kind of issue with how it's configured (like trying to parse out the wrong interface's messages or something), rather than a bug causing it to fail.
Possible for sure, something related to weirdness with your interface setups. Recent thread where they were seeing the anti-lock out rule on one of their vlan interfaces vs lan, and they too were having issues with rules.
You clearly have something wrong - but what is crazy is you would have the same sort of something wrong on multiple setups.
Kind of leaning towards @tinfoilmatt suggest, just start clean.. When you have logging working.. Then restore rules on the interfaces. Maybe only backup the firewall rules vs complete restore. But since you would have a clean system, make sure you take a backup of its config.. Before you restore - if the restore breaks the logging you will have files you can compare to what could be causing it.
-
@johnpoz @tinfoilmatt I'll set aside some time in the next few days to rebuild the home unit from scratch and compare the backups. The thing that gives me pause is that the configuration on this unit doesn't really match up in any meaningful way to any of the other machines exhibiting the issue.
I found another machine exhibiting it, which only began having the issue on the upgrade to 25.11. That one hasn't had its logs cleared, but it hasn't logged a single blocked packet (despite definitely blocking many) since the upgrade/reboot. It's a completely different piece of hardware (an old C2358 machine with a CF card I use as an IPSec endpoint). Bafflingly, rolling back to the 25.07.1 boot environment does not fix the issue - it's still not logging blocked packets it's configured to log even after booting the old version and config. Comparing the config versions from enabling the firmware upgrade until today reveals absolutely nothing amiss changing in the config (below). I found yet another machine that hasn't logged blocked packets since a 123 seconds after booting into 25.07.1 (which was a clean install on a 7100). It booted, logged blocked packets for about two minutes, then stopped.
--- /tmp/be_mount.6rG2/cf/conf/backup/config-1765562644.xml 2025-12-12 13:04:44.807537000 -0500 +++ /tmp/be_mount.6rG2/cf/conf/config.xml 2025-12-19 09:58:05.558321000 -0500 @@ -1,6 +1,6 @@ <?xml version="1.0"?> <pfsense> - <version>24.0</version> + <version>24.1</version> <lastchange></lastchange> <system> <optimization>normal</optimization> @@ -870,9 +870,9 @@ <qinqs></qinqs> <laggs></laggs> <revision> - <time>1765562644</time> - <description><![CDATA[admin@a.b.c.d (Local Database): Saved firmware branch setting.]]></description> - <username><![CDATA[admin@a.b.c.d (Local Database)]]></username> + <time>1766156285</time> + <description><![CDATA[(system): Overwrote previous installation of System Patches.]]></description> + <username><![CDATA[(system)]]></username> </revision> <captiveportal></captiveportal> <gateways> @@ -901,7 +901,7 @@ <refid>67574832baa75</refid> <descr><![CDATA[GUI default (67574832baa75)]]></descr> <type>server</type> - <crt>different cert info here==</crt> <prv>different cert info here</prv> </cert> <dhcrelay></dhcrelay> @@ -947,7 +947,7 @@ most secure, easiest to use, and simplest VPN solution in<br /> the industry.]]></descr> <pkginfolink>https://github.com/pfsense/FreeBSD-ports/commits/devel/net/pfSense-pkg-WireGuard</pkginfolink> - <version>0.2.9_5</version> + <version>0.2.11</version> <configurationfile>wireguard.xml</configurationfile> <include_file>/usr/local/pkg/wireguard/includes/wg.inc</include_file> </package> @@ -955,7 +955,7 @@ <name>System Patches</name> <internal_name>System_Patches</internal_name> <descr><![CDATA[A package to apply and maintain custom system patches.]]></descr> - <version>2.2.23</version> + <version>2.2.26</version> <configurationfile>systempatches.xml</configurationfile> <include_file>/usr/local/pkg/patches.inc</include_file> </package> @@ -971,7 +971,7 @@ agility. Whether you're scaling deployments or streamlining network management, Netgate Nexus delivers the control and customization you need to stay ahead.]]></descr> - <version>25.07.1_1</version> + <version>25.11</version> <configurationfile>nexus.xml</configurationfile> </package> <menu> -
@beatvjiking well something is common between all the units causing the problem. Finding out what that is the question.
If it was some huge bug in 25.11 - why isn't mine showing the problem.. Why are not the 1000's or prob more like 10s of thousands of units out there now running 25.11 not having the issue?
I would think if was some common thing causing the issue - the boards would be a flame with people reporting the issue, etc.,
So I think the best way forward is since your home system rebuild would cause the least disruption is to attempt to find what is the root of the problem with it. And then that hopefully points to the common thing that is causing it in your other systems
-
@johnpoz I agree, and I'm going to move forward with the rebuild, and will update after. I just am baffled by this - based on my experiences and the breadth of configurations and systems the issue crosses, it seems like a bug; but as you say, if it were a bug one would expect more people would be seeing it.
-
@beatvjiking well it could still be a bug, but only triggered by some not so common thing. Do you use a specific package across the systems?
But yeah its not a bug in the sense that everyone, or big common base of users are hit with it.
-
@johnpoz the only common package in use is System Patches, and there aren't any non-package-provided patches installed. I'll keep digging.
