Messages

And that may also be circumvented by using the IP on itself, since AG Home is never asked.

My thoughts also. When I attempted to block DoH, I went looking for an IP list rather than a domain blocklist, assuming at least some clients will attempt to reach a DoH server directly without first resolving a hostname.

The default monitor address (derived from the gateway) may fail, or be slow, to respond to ICMP requests. Try changing the monitor IP in the gateway settings.
The delay also looks rather large IMO. If you disable the 'loss' series in that graph, you will get a finer grained view of the delay (RTT). I expect that will also improve if you change the monitor IP.
Of course none of this will improve your connection but it may give a better indication of the real state of the link.

If you're referring to the memory use reported by Proxmox and you've recently upgraded to PVE9, this may be due to the change in the way PVE9 gathers memory stats vs what the FreeBSD qemu-agent provides.
VM Memory Consumption Shown is Higher
I've seen this after upgrading to PVE9 and now rely on telegraf stats to monitor opnsense memory use.

Seems this is not possible without modifying suricata.yaml or the jinja template, to have a nested include in vars.address-groups.
Yaml config does not support overlays. I want to avoid modifying package files :-(

If I wish to change say, vars.address-groups.SMTP_SERVERS, what syntax to use in /usr/local/opnsense/service/templates/OPNsense/IDS/custom.yaml without having to re-declare the entire vars.address-groups?
Many thanks.

So floating filter - interface NAT - interface filter ...

I'm putting that on a sticky note above my monitor!

Do I need a floating rule for this tagging case, or is it sufficient to use a plain OUT interface rule on WAN with the same rule content: block on "Match local tag = NO_WAN_EGRESS"?

I have a similar match-tag and drop rule defined as a floating rule. I tested it ages ago, and it worked. It does seem a foolproof approach to preventing VPN leaks and it is independent of any NAT addressing.
Looking at my floating rules, few if any of them would seem vulnerable to unintended outcome due to a misunderstanding on my part regarding when NAT occurs WRT rules.
I was not familiar with the option to define out rules on interface prior to coming to opnsense. Therefore, I've stuck with defining them in floating only.
I think I will revisit floating rules having come across this thread.
Thanks.

Thanks. Just a matter of interest on what was planned for the new mvc based rules management. It looks promising and I'm looking forward to trying it some time soon.

I was thinking of fw rules that are created when 'filter rule association' is enabled in a port-forward rule. The corresponding rules can be manually reordered whilst their association with the port forward rule (as shown in the UI/config) remains intact.

I formed the impression the new firewall management would ultimately supersede the existing method, much like how OpenVPN has been modernised. I also formed the impression that the new automation was not intended solely to expose the rules via the API but aimed to offer improved fw rule management generally. I was not worried the existing method was suddenly going to disappear though :-)

Thanks.
When automation rules eventually supersede firewall rules, will port-forward rules create their corresponding firewall rule under automation rules? Will that functionality remain available?

After several weeks on and off troubleshooting the problem, it turned out to be nothing to do with opnsense or my pbx. The issues were with the other end's fttp/voip setup! Consider the above a red herring.

I think the OP is referring to layout and colors within a rule definition rather than the organisation of a list rules.

Regarding migrating existing conventional rule definitions to the new MVC based rules. If I were to do it piecemeal, say convert floating rules, then later rules for one interface, is there a possibility of unexpected consequences with, for example, rule ordering?

Thanks franco. Appreciate the information. 25.7 is running well for me.

ovpn_status.py should, when called, return the specified instances json and exit. For me, it generally completes successfully other than the odd time when using the api to restart and check an instance. I never see the issue otherwise. Does your setup involve restarting openvpn instance(s) on the hour?

I was thinking solely of the visibility of the firewall interface address aliases. But I see the scope for problems.
Thanks for the comprehensive answer.