Messages

This is still a complete mystery to me - anyone know?  I've done a complete uninstall/reinstall and it's working now in general, but this configuration still makes no sense to me.

FWIW - to answer my own question.  This seems like it was somehow a bug caused by the 1.14 upgrade.  I see now the documentation says it's explicitly an AND condition, which I didn't see before.  I had to do a complete uninstall/reinstall of Zenarmor with 1.14 for other bugs, and suddenly the policies started matching correctly afterwards. 

Config naming is a little confusing too in username vs access key, especially that host is FQDN, but works!  Can officially retire legacy ddclient, thanks all.

Ahh ha, that was it.  I saw the mention of 'native' but didn't realize it was a non-default setting that needed to be done.  Thanks!

So in the 23.7.2 announcement it says Route53 was added as a backend to ddclient, and points to the 1.15 change log.  However, after upgrading, I do not see Route53 listed as a backend.  Is it pending an update to the front-end to expose it?

Is the policy matching rule evaluation listed somewhere?  I read through the documentation, but can't find how it actually combines evaluations.

I presently have it set to an interface, with a vlan specified, and then a specific subnet of IPs.

However, it seems to match all traffic on that vlan, ignoring the specified IP subnet.  I'd expect these to be evaluated with && not || - is that wrong?

With 1.14, there are two panes with seemingly redundant configuration options.

I use remote elastic DB - in settings->configuration, I configure the remote reporting database as elastic.

In settings->data management, I then configure it again, though slightly differently.

It appears to be working, except that in data management, it indicates that it isn't working with '200 remote database connection failed'.

I have data in the dashboard/reports/etc though, so I'm pretty sure it is working, and this configuration is just.. wrong? broken? does something else but has the same name?


Also, please get rid of the annoying sidebar balloons.  They're asking me to submit feedback every time I click on Zenarmor - my feedback is that is super annoying and also is not consistent with the OPNsense UI.  I have no interest in the cloud portal, which is why it's turned off.  Nagging me every single time I use it is not improving your situation there.

How would you solve the issue via a remote session for an upgrade failure?  Doesn't make much sense in the approach. 

I understand it as a general policy to troubleshooting, but can't see how it's relevant for this one.

It's also a bit of an uncomfortable approach with a firewall device.

Submitted a bug, got a blow off "we can't reproduce, go away" response.  Meh - think it's best to just avoid using Zenarmor in the future.

I was upgrading from 23.1.6

I do use Suricata as well,  but obviously on different interfaces.

There is no such log file on my host, only a zenarmor_updates.json

I don't have too much information to really provide on this.  However, when performing the upgrade to 23.1.7 today, it reached upgrading Zenarmor/os-sensei to 1.13.  At this point it gave a message that it was saving state as it was running, and then "Waiting for PIDs: ..." - at this point the opnsense system went entirely unreachable and stopped forwarding traffic entirely.  After waiting for several minutes in this state, I had to use out of band console to go in and kill all eastpect processes, at which point the OPNsense system functioned again.

Yeah, that's not the issue here, because the upload_sftp script works if I call it manually.  I ran into that same problem with ESXi - I believe it's because it can't chmod.  This is just a plain jane Ubuntu 22.04 server it's uploading to.  Very odd.

Gives me a green OK result.  Pretty sure it's calling the upload_sftp script with the test params, which also work.  Just running the automation only ever produces that one configd log line and nothing else, which is very odd. 

Any thoughts?  I actually added some messages to try and debug, but they don't fire when run via the web gui or automatically.  Makes me think that whatever is supposed to actually call the script is doing something wrong - but I'm not exactly sure of that process flow.