Little cosmetic issue after upgrade to 25.1.1

[IsaacFL]

I'm out of town until Friday so can't try the patch yet.

The things that seemed to trigger from my memory:
I had a NAT forward rule  to forward DNS port 53 to my local piholes. I could disable the port forward and the log entries would go away

Another ipv4 log entry was ping to 1.1.1.1 from the WAN address. I am mostly ipv6 network and have Tayga plugin. Some Apple clients like to ping 1.1.1.1 via CLAT and so they go thru the Tayga

[franco]

Thanks for the details. For now we're looking for the internal error code ("reason") which indicates the nature of the code problem, it may or may not be related to the rule content.

Just to reiterate. The actual fix will go into 25.1.4 as planned, but we still need the additional data to have the right approach in FreeBSD eventually.

Appreciate the help.  :)


Cheers,
Franco

[gpb]

I can do this later today but I need to understand exactly how to extract the logs to get them to you (I want to get it right the first time).  BTW, I have similar NAT rules as IsaacFL indicated for DNS and NTP...but I'm sure a lot of people do.

[franco]

The output of

# opnsense-log filter

may be enough after reboot when you saw the bad entries appear with that specific kernel.

You can also share it privately via franco@opnsense.org


Thanks,
Franco

[gpb]

You can also share it privately via franco@opnsense.org

Thanks,
Franco

Sent.

[franco]

Thanks! Based on the data we're looking at state creation failure here, which may be perfectly normal on bootup:

https://github.com/opnsense/src/blob/ba418a9ea69182d01a12e39f0a76a6b4ca9a99bd/sys/netpfil/pf/pf.c#L5330

(it's going to be reviewed by FreeBSD so we'll know for sure soon enough)


Cheers,
Franco

[IsaacFL]

The question in FreeBSD came up why these state creations are rejected.  The other half of the story is the log does not actually record this at the moment either way. I wrote a small patch to diagnose: https://github.com/opnsense/src/commit/6f18c3b0164689d5cc83206499ade2f4f4016c6e

Would someone with the issue here try this kernel build and send in the plain filter log for the entries that cause spurious block log messages after boot?

# opnsense-update -zkr 25.1.3-reasonlog
(reboot)


Thanks in advance,
Franco

Im back in town and will try this patch today.
Update: Installed, can see the unexpected log entries again. Let me know when you would like me to send output of opnsense-log filter

[newsense]

Can you try this kernel as well ?

Code Select Expand

opnsense-update -zkr 25.1.3-states

[franco]

Nope, not this kernel ;)

[newsense]

Ah sorry, think I know now what that's for

[IsaacFL]

The question in FreeBSD came up why these state creations are rejected.  The other half of the story is the log does not actually record this at the moment either way. I wrote a small patch to diagnose: https://github.com/opnsense/src/commit/6f18c3b0164689d5cc83206499ade2f4f4016c6e

Would someone with the issue here try this kernel build and send in the plain filter log for the entries that cause spurious block log messages after boot?

# opnsense-update -zkr 25.1.3-reasonlog
(reboot)


Thanks in advance,
Franco

Im back in town and will try this patch today.
Update: Installed, can see the unexpected log entries again. Let me know when you would like me to send output of opnsense-log filter

Franco, I emailed you a copy of the filter logs and my rules.debug

[IsaacFL]

I noticed after updating to 25.1.4_1 that this issue is still active.

Did the patch not get put in this update?

# opnsense-update -zkr 25.1.3-fixlog had fixed it prior

[franco]

We didn't update the kernel yet for unrelated reasons. It probably reverted back to 25.1.3. Next kernel with the fix will be 25.1.5.

I got your mail, but was a bit swamped this week. Will reply next week.


Cheers,
Franco

[newsense]

# opnsense-update -zkr 25.1.3-fixlog had fixed it prior

It is expected that an update will revert to the latest released kernel - so when running a custom version with a particular patch you need to either confirm the new one has the fix included or get in the GUI and lock the kernel before the updates.

The good news here is that the patched kernel is still available and you can simply run the command and reboot