Unsolicited log lines with empty description

[openMe]

Hello,

I have a plain setup of OPNsense (2 node HA, 24.7.9_1, manual NAT outbound rules as of HA description) and created some rules. Now whenever a rule gets matched to let a packet out the WAN I see two lines for the WAN interface: one has my local client IP as the source and no comment aka description in the last column, the other one shows the NAT VIP and my rule description ("Replacement rule..."):

Code Select Expand


WAN 2024-12-07T08:03:58 NAT-IP:37572 DESTINATION:123 udp Replacement for let out anything from the firewall host itself
WAN 2024-12-07T08:03:58 CLIENT-IP:57646 DESTINATION:123 udp
LAN 2024-12-07T08:03:58 CLIENT-IP:57646 DESTINATION:123 udp Allow Internal_LANs to ANY


Clicking on the "i" icon at the end of the middle line (the one without a description shown) reveals an empty rid attribute and rulenr is 1.

1. Where are those lines with an empty description coming from? IMHO I've searched every - self-made and automatic - rule and can't find one without a description.
2. How can I get rid / suppress the logging of those lines without a description? I've already turned off every option under Firewall -> Settings -> Advanced -> Logging.
3. How could I put a comment in these rules, if I decide to keep, instead of suppress, them?

Kind regards

[OPNenthu]

It's possibly this: https://forum.opnsense.org/index.php?topic=44099.0

My NAT rules show up like this in 24.7.9_1 but it looks like a fix went into 24.7.10.

[openMe]

Thanks, that seems the cause. Glad to see that there already is an issue set up.

[franco]

Unsolicited is a bit funny, because you added the log checkmark to the NAT rules in question. BTW you can even see the NAT as it is applied because the NAT log line is pre-NAT and then WAN out is post-NAT.

The action display is fixed in 24.7.10 (was an upstream issue) and the NAT rules don't support labels so no labels can be shown.


Cheers,
Franco

[openMe]

Thanks for further explanation. Would you be so kind to tell me (as a newbie to OPNsense) what you mean by "NAT log line"?! In my code snippet I only see one LAN log line and two WAN log lines. Of cause I guess you mean the middle log line (the line in question), because this line is pre-NAT and the topmost line is post_NAT. But for me, again as a noob, I wouldn't know that it is a "NAT log line", for it says WAN at the line's start.

From my point of view the middle log line seemed unsolicited for I did not know that NAT rules don't support labels.
Honestly, I haven't seen this in the documentation (admittedly, I flew over the docs  8)). Can you please point me there?

Now I know I can't show up a label for it, but I can suppress the line by disabling logging for my manual generated NAT rule. Thanks again.

[franco]

> From my point of view the middle log line seemed unsolicited for I did not that NAT rules don't support labels.

I'm not sure this is in the documentation. The NAT rule logging was added last year by us to FreeBSD, but it just follows the actual behaviour: if you set logging in the NAT rule a NAT log line with the appropriate NAT action will appear.

As for labels not available for rules.. that's a pf (packet filter) limitation in BSD.

> Now I know I can't show up a label for it, but I can suppress the line by disabling logging for my manual generated NAT rule. Thanks again.

Yes, my point. Adding the logging to a NAT rule is opt-in, not opt-out.

From in to out:

LAN      2024-12-07T08:03:58   CLIENT-IP:57646   DESTINATION:123   udp   Allow Internal_LANs to ANY

^^^ logging on incoming packet (from firewall perspective), likely pass action

WAN      2024-12-07T08:03:58   CLIENT-IP:57646   DESTINATION:123   udp      

^^^ NAT rule action (nat, rdr or binat depending on rule type) kicking in on outgoing packet (from firewall perspective), note the client IP is still visibe (pre-NAT)

WAN      2024-12-07T08:03:58   NAT-IP:37572   DESTINATION:123   udp   Replacement for let out anything from the firewall host itself   

^^^ Packet forward action on outgoing interface (pass) and client address no longer visible (post-NAT)

That's all there is to it.


Cheers,
Franco

[OPNenthu]

@openMe, I struggled with this too.  It's likely that we both came to OPNsense at a time when the NAT live view had a bug, so we never experienced how it should look.

Once we upgrade to 24.7.10 which has the fix, I believe the NAT log lines in the live view will be blue in color and will have a different indicator in the left column.

See here for example (Figure 38, bottom): https://www.zenarmor.com/docs/network-security-tutorials/how-to-configure-opnsense-nat

(Curious why that image has a label showing up on the NAT rule?  Did 'pf' support it at one point, @franco?)

[franco]

> (Curious why that image has a label showing up on the NAT rule?  Did 'pf' support it at one point, @franco?)

Maybe this got lost somewhere during a refactor. Trading a GitHub ticket for a code treasure hunt.


Cheers,
Franco

[franco]

Checked the code and this is still there, but obviously wasn't working because of the root cause which always said 'pass':

https://github.com/opnsense/core/blob/988dbae92d966fee3590e996b138f5e0a7dfcb97/src/opnsense/scripts/filter/read_log.py#L147-L149

This suggests ts it back to working order now?


Cheers,
Franco

[OPNenthu]

Trading a GitHub ticket for a code treasure hunt.

Thanks.  Sorry, I assumed it was a simple yes/no answer (from memory of how the product worked before) but you literally took the time to look up git commits.  I will be more careful what I ask ;) 

The link is helpful.

I've not updated to 24.7.10 yet.  Maybe OP can confirm it.

[franco]

Usually we ask for tickets for traceability, but this case had me wondering. I can't test this at the moment due to other priorities but a quick code search is always helpful.

Given the above-average silence on the issue it should work as expected again.


Cheers,
Franco