Outbound Nat Rewrite - how to monitor in logs?

[franco]

Hi,

Pete and me exchanged a few messages on GitHub. Basically, NAT logging is possible, but has some caveats...

Nevertheless, two patches can help with this in the future:

https://github.com/opnsense/core/commit/3eb235f25

We want to be able to search for "rdr" (port forward) or "nat" (outbound NAT) logs directly.

https://github.com/opnsense/src/commit/bdb244c37

The logging already works for builtin "pass" NAT rules, but with an associated firewall rule the logging is muted. Furthermore, while post-NAT logging makes sense for the associated firewall rule the NAT logging should probably be done pre-NAT as it would match the packet.

You can see the result in action here:

https://github.com/opnsense/core/issues/5005#issuecomment-871176383

I think that addresses all problems discussed here?


Cheers,
Franco

[allebone]

Many thanks. Yes it has resolved the issue.

I posted a screenshot anyone else in this thread can now view on:
https://github.com/opnsense/core/issues/5005

That shows how logging now looks with this patch. It is working for me and I will continue to monitor it for any undesirable effects but so far clients accessing port 53 are rerouted to my internal DNS and now logged correctly so it appears everything is working as desired and this provides logging as desired so it looks really good to me :)

Kind regards
Pete

[cookiemonster]

I've been watching with interest. I thought being new to OPN I was not setting up things correctly. I was glad when I saw the thread. Also I was waiting for the OP to respond to avoid spoiling.
My question is I am on 21.1.6 . Can I use the patches on it or do I need to upgrade to 21.1.7 first if I want to try the patch?

[allebone]

Updating puts you on the release candidate version. Checking for updates normally would revert you back down to before the next version so you will lose the patch.

You would essentially be temporarily on a dev version and only able to update once the version catches up to where the patch is, or you will lose the patch.

A reboot is required when changing. Basically I will have to now wait until the community version catches up to the version I am using, or update and lose the patch and then have to wait until the patch makes it into the community version. It apparently wont make next version so I will have to decide to wait for 2 new versions to be released where the patch will likely make it in or instead update as normal and be without it for 2 versions until we catch up to when it will make it into the community version.

One thing I would say is being split between packages like this (because only one module is updated by running the command on github) means you are not on a snapshot of an official release, so obviously its going to be unsupported and not fit for business use etc. At home you can feel free to make the call. Depends how adventurous you are. I kind of feel its fine personally, so will probs just leave it and update only again in 2 versions time (2 months?).

P

[cookiemonster]

understood. Thank you.

[franco]

Hi,

It's not overly problematic. The kernel needs to be switched, but all other parts are untouched / allowed to be updated.

The snapshot kernel itself is basically 21.7-RC1 with the added fix on top. Deviation from 21.1x is minimal except for some driver updates.

# opnsense-update -zbkr 21.7.r_1
# opnsense-update -Lk
# opnsense-shell reboot

The above will install the newer kernel and lock it to prevent minor updates from overwriting it. You can always unlock the kernel from the GUI and reinstall the official release one or issue:

# opnsense-update -Uk
# opnsense-update -k
# opnsense-shell reboot


Cheers,
Franco

[cookiemonster]

Most obliged franco.
I'll do that once I've settled a few kinks I have so I don't make changes whilst resolving.