Messages

And yes I've forwarded DNS and NTP requests to the loopback address. This means, you can also use the interface group in port forwarding rules.

I have been doing the same. One minor gotcha I encountered, some pre-existing rules allowing access to locally hosted services by way of an RFC1918 alias, had to be updated. Otherwise it seems a robust technique and served as a workaround for issues I've had in the past where a service was just not listening on all interfaces despite setting it as such. This wasn't in opnsense BTW.

On a lighter note, BBC just came out with this! "It was supposed to be kept quiet until everyone had a chance to fix their sites - but the news was leaked."

and can be updated by the system in the future.

So that feature will be added back in the system again in the future ?

I take franco's clarification to mean the 'register' option does indeed maintain a linked fw rule and that it will be updated whenever changes are made to the 'parent' NAT rule. I think my understanding re the new firewall was therefore wrong.
Create a NAT rule with option register, change some aspect of the NAT rule and see if those changes are reflected in the 'registered' fw rule.

I'm not sure where I got the following impression from, but my understanding of current NAT/Rule linkage is, choosing 'firewall rule' creates a rule for you but the association is not maintained (where it may have been before the overhaul). i.e. now, if you edit the port forward, the generated firewall rule does not get modified. I haven't tested this assumption as I tended to maintain firewall rules, even those associated with NAT, manually.

Now I'm nervous we've been wasting effort - we have several deployed systems where we've customised the rspamd plugin configuration to enable DKIM,as per this post:

https://forum.opnsense.org/index.php?topic=20280.msg270642#msg270642

 - is there a risk that configuration work will be lost on the next service/firewall restart?

I am not familiar with rspamd or its opnsense plugin. However part of your howto refers to creating files in `/usr/local/etc/rspamd/override.d/`. This suggests it is set up in such a way that it loads custom config from there. Providing scope for your DKIM conifg without fear of it being ignored/overwritten. Postfix as far as I am aware doesn't provide this include mechanism. The directives are invariably in main.cf and that is very likely overwritten by the plugin.

AIUI the settings for opnsense and its plugins can/should all be found in config.xml. Each time you change them (via UI or API directly) or when you restart the appliance, the respective daemon (unbound, postfix etc) configuration is written out to file. Unless a plugin's associated services have been set up by the plugin developer to read in additional custom config from static files (like unbound), any changes you make outside the API likely are ignored or overwritten. With the postfix plugin, there may be no provision for custom files and since much of postfix's functionality depends on this approach, you may be stuck for time being.
I would look at what's written out to the filesystem when you make changes to postfix via the OPNsense UI. It may give a clue as to what might work or is broken when entered via the rewriting dialogs in the UI.
If the plugin is broken, I guess an alternative may be to install postfix, without plugin, and manage its config directly.

[...]adding IPS/IDS in the future when I start messing around with hosting my email server[...]

I do have some advice here: If you block traffic with the IPS, see if any of the matches affect your systems and watch for false positives. And performance, of course. I ran various IPSs for years (2004-2024); I stopped running one against my servers as I never saw matches that would affect my systems, but I did see false positives on mail messages. I don't bother with it at all these days (with OPNsense). As always, YMMV.

I think this is very good advice. For mailservers rely on RBL, postscreen (if using postfix) and fail2ban.

Hello,

any feature that might use it falls back to NDP and ARP when disabled.

If it's that way forever is unclear right now.

Thanks @Monviech for the clarification.

I have the service turned off because I don't perceive a need for it in my case. AIUI only Captive Portal and MAC based aliases/firewall rules currently require it. Is that correct and what other OPNsense functions may come to depend on it in the future?
Cheers.

What it also is very clever at, is making suggestions at how I can add and improve things. It wasn't my idea to add all of the monitoring

I only have experience of the free online LLMs and very recently running local models with LM studio. So far, I have only used it to generate (hesitate to use the word create!) standalone or loosely coupled shell or python scripts. I'm now hoping to attempt some larger projects, so I asked AI what's the best approach for specifying project requirements: An overview with use cases expressed entirely in natural language vs additionally specifying requisite technologies, libraries etc. The AI favoured the second approach. Moreover it recommended specifying details such as database schemas. In order to avoid project drift and unnecessary complexity! ;-)
Regarding the monitoring, I would have preferred a solution that integrated the service typed you wanted monitoring in to an existing monitoring system. e.g. by creating nagios plugins for those services not already covered by available plugins.

Very impressed with Google AI, I have never written Powershell scripts, but they are all working perfectly. I'm glad I've retired!

I worked on and off in surveying, IT operations and ecommerce. I can honestly say I derived most job satisfaction from coding and task automation. Now AI can do all of it. I really cannot see it ending well but that's age based skepticism, I hope!

@OPNenthu Dealing with the problem before the queries hit a DNS server is the favourite solution IMO. Thanks for posting (post #25).

Thanks @franco. I can confirm 26.7.2 fixes the Loaded# counts in the alias list table.

Following the upgrade to 26.7, telegraf requires running as root in order to read pf stats.

telegraf 1.39.1_1
os-telegraf 1.12.15

Sorry to hear it's had a relapse. Mine has been furiously querying the same hosts in logs.roku.com ever since your OP. Consequently it spends 21 hours a day turned off via smart plug! From the hostnames concerned, it would seem associated with the Roku OS itself rather than some errant app. Idiotic behaviour.