Anyone know what this error could mean.
-
@vbjp
-f tells it load load from the file specified, the v is for verbose output -
It tries to manually reload the generated ruleset and has verbose output so any errors will show.
One other thing that can present like that if the ruleset is good is if the upgrade didn't complete correctly and there is a mismatch between the kernel and pfctl.
Try running:[22.05-RELEASE][admin@2100-3.stevew.lan]/root: pkg info -x 22.01 pkg: No package(s) matching 22.01And:
[22.05-RELEASE][admin@2100-3.stevew.lan]/root: freebsd-version -kur 12.3-STABLE 12.3-STABLE 12.3-STABLESteve
-
output of pkg info -x 22.01
pkg: No package(s) matching 22.01output of freebsd-version -kur
12.3-STABLE 12.3-STABLE 12.3-STABLEoutput of pfctl -vf /tmp/rules.debug attached as file removed IPs
Thank you.
-
Hmm, so it loaded without generating errors?
I note you have a duplicate negate networks table. That's unexpected and fixed in 22.09 but shouldn't cause this.
Steve
-
It was one time occurrence, got bunch of errors, internet broke, rebooted and it works ok, not sure why it happened. Hope it does not return. But for now no problems.
-
Ah, in that case I suspect that there may have been a mismatch at that point before you rebooted.
Was that the first time you rebooted since upgrading?
Steve
-
No it was at least 3rd reboot after upgrade. I rebooted once just after upgrade. Then few days later rebooted because dns broke. Upgraded to 22.05 on first week of release.
-
Hmm. If you see it again try to run those two command before rebooting to check for a mismatch.
If it's not doing it now though it's hard to say what might have caused it for sure.
-
I am experiencing the same issue. Ver. 22.05
pfSense started to print this error after I installed mtr-nox11 package.There were error(s) loading the rules: pfctl: pfctl_rules - The line in question reads [0]:No package(s) matching 22.01
12.3-STABLE
And I have no portforward at all.Not sure why, but I also have a duplicated ruleset, which is my OpenVPN Tunnel Network.
[22.05-RELEASE][root@g.localdomain]/root: egrep -v '^#|^[[:blank:]]*$' /tmp/rules.debug | sort | uniq -c | grep -v '^ 1 ' 2 table <negate_networks> { 10.22.0.0/24 }This box was working nicely in the past 152 days without any issue till today's mtr package install. I have removed the package, but I am still receiving the error message, when for example I restart the OpenVPN.
The previous post was in August, is there any information since than what causes this error?
Thank you! -
It's this: https://redmine.pfsense.org/issues/13408
It's caused by the new layer2 rules in 22.05. So that's mostly captive portal.
It's not related to that package and the duplicated negate_networks table is unlikely to be a problem.
Steve
-
Thank you Steve for the info.
I've read through the topic mentioned in the ticket.
Someone wrote that he changed the OpenVPN config then the issue has started.
Actually, besides the mtr installation, I also changed the OpenVPN config, nearly at the same time, therefore yes, might be not the mtr installation, but the OpenVPN changes triggered the issue. -
As far as I'm aware it should only happen with Layer 2 type rules which wouldn't normally appear in an OpenVPN config.
Are you running the captive portal? -
I don’t use captive portal.
The topic mentioned in the ticket states that only captive portal incorporates layer 2 rules, however at least 3 people are saying that they don’t use captive portal at all. -
For most users who see that it clears at reboot. Is that the case here or is it now persistent since you made the OpenVPN change?
Can you roll back that config change as a test? -
I haven't rebooted the box just in case further debugging is needed, therefore the issue is still present.
The firewall is forwarding some traffic, but because of this error I assume not all rules are applied. I've read that reboot made situation worse for someone, therefore this was also against the reboot, and I was thinking to leave it as it is for now.Since the reboot likely clears the issue, therefore is the goal to restore the previous configuration without reboot and see if no more error messages will be printed? Do I understand correctly? If yes I am happy to visit the firewall in the evening and restore the config.
Do I need to have a USB drive with the 22.05 image handy? :) -
If you somehow create an invalid ruleset the packet filter will refuse to load it and continue with the existing ruleset. That can be confusing because it appears as though any new firewall rules you add are not being respected. In that situation if you reboot the invalid ruleset cannot be loaded at boot and you may end up with no rules. Generally bad!
However this error is not due to a bad ruleset. It happens when the code gets stuck loading a layer 2 rule as I understand it.
Check your /tmp/rules.debug file for any layer 2 (ether) rules like:
# Captive Portal ether pass on { ix2 } tag "cpzoneid_2_rdr" ether anchor "cpzoneid_2_auth/*" on { ix2 } ether anchor "cpzoneid_2_passthrumac/*" on { ix2 } ether anchor "cpzoneid_2_allowedhosts/*" on { ix2 }Steve
-
[22.05-RELEASE][root@g.localdomain]/root: grep ether /tmp/rules.debug [22.05-RELEASE][root@g.localdomain]/root:It seems there are no Layer 2 rules
-
Hmm, in that case it's unclear what might have caused that....unless you might have had ether rules at some point?
-
There were no ether rules configured in the past.
This is a very simple firewall, only 3 packages installed (aws-wizard, ipsec-profile-wizard, openvpn-client-export), HFSC scheduler with floating match rules and tagging for Internet upstream, some vlan interfaces with inbound rules. I think I had one static route previsouly but it has been deleted long time ago. Nothing else.
-
Well as far as I know there is no way to clear that error once it has been hit other than rebooting so I'm not sure you have any other choice. Beyond just allowing it to run as it is with the current ruleset.
Without any ether rules there I would expect it to boot back OK.
