Strange error: There were error(s) loading the rules: pfctl: pfctl_rules

[ChrisJenk]

I have a NetGate 3100 running pfSense 22.05. The system was stable and working well. Yesterday I made quite a few config changes. Later I noticed some alert notifications. There were a few of them but they all said the same thing (just different timestamps):

There were error(s) loading the rules: pfctl: pfctl_rules - The line in question reads [0]: @ 2022-08-04 19:43:08

This sounds rather concerning. As far as I can tell everything is still working correctly but I haven't rigorously tested every single firewall rule. The message isn't very helpful as it doesn't identify which rule(s) it relates to nor why they are problematic. I have looked in lots of different logs on the system but I couldn't find anything more to help me diagnose/rectify this.

The error is now appearing every time I do anything that requires the rules/filters to be reloaded.

I'd like to understand:

• Is this a real error or just a bogus error report?

If it is a bogus error:

• How can I stop it from appearing every time the rules/filters are reloaded?

If it is a real error:

• How can I identify the rules that are causing a problem?
• How do I determine exactly what about said rules is problematic?

Also, errors such as this need to be far more detailed and descriptive. This message is very poor in its information content.

I have found other threads reporting similar issues. I ran pfctl -vf /tmp/rules.debug but the output just said:

pfctl: pfctl_rules

And the exit code was 1 (which implies an error).

Appreciate any help!

[ChrisJenk]

Update: After rebooting the unit the problem seems to have gone away. Rather disconcerting...

[stephenw10]

Was that immediately after upgrading to 22.05?

Did you check if there were any rules in /tmp/rules.debug?
I'm not sure I've ever seen that command return nothing like that.

Make sure you can run Status > Filter Reload in the GUI without errors now.

Steve

[ChrisJenk]

@stephenw10 said in Strange error: There were error(s) loading the rules: pfctl: pfctl_rules:

Was that immediately after upgrading to 22.05?

Did you check if there were any rules in /tmp/rules.debug?
I'm not sure I've ever seen that command return nothing like that.

Make sure you can run Status > Filter Reload in the GUI without errors now.

Steve

No it wasn't. I updated to 22.05 several weeks ago and have made many changes since then, with no problems. It was just late yesterday, after a lot of changes (including one which removed a WireGuard interface) that the problem started happening.

The /tmp/rules.debug file contains lots of rules (417 lines worth in fact).

Since rebooting the unit I am able to perform a filter reload with no errors reported.

[stephenw10]

@chrisjenk said in Strange error: There were error(s) loading the rules: pfctl: pfctl_rules:

The /tmp/rules.debug file contains lots of rules (417 lines worth in fact).

That's after rebooting though? I was just wondering if you had checked it at the time when it was throwing the error.

[ChrisJenk]

@stephenw10 said in Strange error: There were error(s) loading the rules: pfctl: pfctl_rules:

@chrisjenk said in Strange error: There were error(s) loading the rules: pfctl: pfctl_rules:

The /tmp/rules.debug file contains lots of rules (417 lines worth in fact).

That's after rebooting though? I was just wondering if you had checked it at the time when it was throwing the error.

I checked it, and ran the command, before rebooting and after rebooting. Before the reboot, the file, which contained a lot of rules, gave the exit code of 1 and the one after the reboot, which also contained a lot of rules, did not. Of course, I stupidly forgot to preserve the before reboot version of the file so I am not able to compare them :-(

[stephenw10]

Hmm, well if you see it again backup the file to check.
I've been unable to replicate that error here so far.

Steve

[ChrisJenk]

@stephenw10 said in Strange error: There were error(s) loading the rules: pfctl: pfctl_rules:

Hmm, well if you see it again backup the file to check.
I've been unable to replicate that error here so far.

Steve

Will do!

[Flole]

I got called to a customer this morning cause "nothing was working" and I'm greeted with the same error here. Even when I create an empty file and try to load it using

pfctl -v -f /tmp/nothing

I see that output with an exit code of 1. Rebooting does not help here, same thing afterwards. Trying to use the x-parameter to set the verbosity to "info" or "verbose" as described in the man page does not work either, the log level is simply not recognized and it fails. EDIT: pfsense still uses the old "loud" name for the debug level. Doesn't shed any light on what's going on though as dmesg doesn't produce any additional output except for pf_map_addr: selected address 192.168.x.y.

So either an empty file is expected to cause this (I don't think so though) or it's not about the rule files content but about something else.

[stephenw10]

You can make it more verbose with extra v flags. But I expect it to at least return something:

[22.05-RELEASE][admin@4100-2.stevew.lan]/root: pfctl -vvf /tmp/rules.bad
Loaded 762 passive OS fingerprints

Returning only an error like that can be a kernel/world mismatch. Has it just been updated?

Steve

[Flole]

@stephenw10 I've ruled out a mismatch (and it worked after the update, so this is most likely not related to the update). The system was rebooted and then this apparently appeared.

The extra -v flags do cause that os fingerprint message to appear, but then only the pfctl_rules thing again with an exit code of 1.

[stephenw10]

Can you run any pfctl command? Like: pfctl -sr

[Flole]

@stephenw10 -sr is quiet but exit code is 0. When I do -sa I even get my configured aliases as a table, so apparently it all worked for a short time after rebooting so the rules and aliases were loaded properly.

[stephenw10]

This is in 2.6 on custom hardware?

[Flole]

@stephenw10 No, it's on 22.05. I'm sure a downgrade would fix it and I have the recovery image here already, but it would probably be better to do further debugging to see what causes pfctl to get in a state where it not longer wants to accept rules.

[stephenw10]

The only time I've been able to explain that is when there was a kernell mismatch causing pfctl not to function as expected with pf in the kernel.

Try:

[22.05-RELEASE][admin@4100-2.stevew.lan]/root: sha256 /sbin/pfctl
SHA256 (/sbin/pfctl) = 4f9310145dfe739126392d77e7cb37d8cf845317f10624fb8b2fd1e408323761
[22.05-RELEASE][admin@4100-2.stevew.lan]/root: uname -a
FreeBSD 4100-2.stevew.lan 12.3-STABLE FreeBSD 12.3-STABLE plus-RELENG_22_05-n202700-3ddaea61055 pfSense  amd64
[22.05-RELEASE][admin@4100-2.stevew.lan]/root: freebsd-version -kur
12.3-STABLE
12.3-STABLE
12.3-STABLE

[Flole]

That matches:

[22.05-RELEASE][root@XXXXXXX]/root: sha256 /sbin/pfctl
SHA256 (/sbin/pfctl) = 4f9310145dfe739126392d77e7cb37d8cf845317f10624fb8b2fd1e408323761
[22.05-RELEASE][root@XXXXXXX]/root: uname -a
FreeBSD XXXXXXXXXXXX 12.3-STABLE FreeBSD 12.3-STABLE plus-RELENG_22_05-n202700-3ddaea61055 pfSense  amd64
[22.05-RELEASE][root@XXXXXXX]/root: freebsd-version -kur
12.3-STABLE
12.3-STABLE
12.3-STABLE

[stephenw10]

Hmm, that's on custom hardware? Updated from CE to Plus?

[Flole]

It was on Plus 22.01, then it got upgraded to 22.05 and it worked perfectly fine. Then there was a power outage so the firewall got shutdown (graceful shutdown when the UPS ran out of battery) and after it booted again this issue started to appear. As there are multiple users affected by this apparently and rebooting sometimes seems to solve it (at least for others, for me it doesn't for some reason) there is probably some nasty bug somewhere. Shouldn't pfctl normally return an error message if something is not right?

[stephenw10]

It does if there's an error in the ruleset, yes. It doesn't if the rules file is empty though:

[22.05-RELEASE][admin@4100-2.stevew.lan]/root: pfctl -vvvf /tmp/rules.bad
Loaded 762 passive OS fingerprints
[22.05-RELEASE][admin@4100-2.stevew.lan]/root: echo $?
0

We have seen devices load a kernel from another storage device but I've never been able to replicate that here. Obviously that only applies if you have more than one drive in the system.
And it doesn't appear to have happened here since the ported kernel is correct.

However the other symptoms point to that.

Are there any errors in the boot log?