Messages

I didn't add any plugins to my installation that didn't come from the opnsense repository if that is what you mean. (see screenshot)

If this is running on a qemu guest, you don't need cpu microcode packages. Though I don't think it does any harm, it's one less package in the mix.

Some time after upgrading to 25.1.9, I seem to be seeing VOIP disconnections when call duration exceeds approx 900 seconds.
Prior to this all calls, including some lasting over an hour, were uninterrupted.
I cannot accurately correlate the problem with the upgrade as there were no calls of sufficient duration for 2 weeks.

Were there any changes in 25.1.9 that might be related?

There is the option in the dropdown to run a remote command via SSH.
You should therefore be able to use that option to run a local command via SSH on localhost. However I'm not sure how you discover the current cert/key/ca paths, should you need it in your script.

I don't think there is a concept of static dhcp with openvpn tunnel network. To assign a consistent IP to each client, you can create client specific overrides for a given username.
EDIT or are you saying you cannot get more than 1 client connected simultaneously because it refuses to hand out addresses other then .2?

Whatever, regular default-deny /state-violation packages should be logged for this rule and not with some other, user-added rule!
That should be clear.

No, that's not how it works. If some rule you define has already matched a packet and acted upon it, that packet will not reach the default block, whether logging is enabled or not. I vaguely recall there being match type rules which allowed you to act on a packet but it still traverse the rest of the interface rules. But don't see that in current opnsense.

The question is, why those packages are logged with the wrong rule!
I disabled the rule and enabled logging of default blocks - and bamm, those packages are logged as "default deny / state violation", which is right!
But when I instead have my last rule logging, it will be logged with this!

So, with default drop logging enabled and your own rule disabled, you see dropped packets logged under the default rule description.
Then, with default logging disabled and your drop rule above enabled, you see packets dropped and logged under your rule's description (however only for the interface concerned).
What's more, if you have both your rule, and the default logging enabled, dropped packets (on that interface) will be dropped and logged by your rule alone. Those same packets will not encounter the default drop rule.
If that's what you're seeing, and its not totally clear TBH, that is what I would expect.
Regarding packets logged under the wrong rule, I believe this can appear to happen and I may have misunderstood your question.

I found this, which is a bit similar:

https://forum.opnsense.org/index.php?topic=20219.0

When those are out-of-sync packages, the question remains why they get logged under this rule, which seems to be wrong.

Post 4 explains how packet filter and states work and gives a likely cause for what you are seeing. In your example above, I imagine you will NOT find any blocked packets with `tcpflags==S`.

The blocks may be TCP state violations. AIUI when you create tcp allow rules, with default allow options, packets other than syn will be blocked if there is no matching state.

Btw: you 3rd rule, redirect NTP to local is an odd rule: it will never be executed, it's already included in the first rule.

Whilst opnsense can create related firewall rules for your NAT rules, you may still have to reorder the resulting filter rules. The resulting rule may even be redundant, as in this case. You can then either ignore it or disable the filter rule in the associated NAT rule.

When applying a filter to the live view, I occasionally spot log lines that are out of sequence date/time wise. Though I have not yet figured how to reliably reproduce this behaviour.
You cannot view this attachment.
opnSense 25.1.8_1

EDIT: More specifically, it seems to be a case of repeated log lines rather than just an ordering issue.

IIRC each IP in the static import must lie within an existing Kea subnet.

I'm not going to run two DNS services just to be able to resolve internal host names. This whole deprecation of ISC has been a mess. ISC+Unbound is exceedingly simple and functional, Kea and dnsmasq are both half-baked.

I felt the same until I read through the updated docs. DNSmasq is primarily being introduced for dhcpd. Using it also for local name resolution (via an unbound forwarding) means no unbound restarts on updated leases. You retain a recursive resolver and still only have two daemons running in order to provide DNS/DHCP. If it all works as described in the docs, I will be more than happy to switch since I was fond of dnsmasq from previous experience.

I do something similar with icinga. The OP wants a notification when the cert has renewed.
I noticed in the acme automation options that there was not an option to run an adhoc local script.
But it just dawned on me, you could use 'remote command via ssh' to localhost to achieve the same.

I would like to have an automation that sends me an email when a particular certificate has been renewed.
Any idea how to do that?

There's the acme plugin's automation commands.
These sadly do not allow for running a local custom script (a security decision AIUI). But you can trigger a remote script (via ssh) following a certificate renewal. I currently do this to reload services on remote hosts, but you could also fire off an email from the remote host.

Thanks.
Alternatively, in the list of CAs, some visual cue to indicate whether the key is present or not. But I guess it comes down to how many CAs/certificates you're managing in opnsense.

It would make it clearer for users if that certificate form's fields are only enabled when the CA key is present.
Also, could the additonal fields, such as country and org be made user editable in the acme plugin certificate request?