Messages

Power down router, power led off, interface leds on, router restart.
Power down switch first, Power down router, stays powered down.
Bios is American Megatrends, reseting bios has not fixed the issue.
WOL is not installed
UPS attached

Anybody had this 'feature'?

Versions   OPNsense 22.7.5-amd64
FreeBSD 13.1-RELEASE-p2
OpenSSL 1.1.1q 5 Jul 2022

I had a similar issue yesterday using Arhuus, used Kent and upgraded ok.

It may be that this issue is related to Zenarmour (based on further investigation).
If this is found to be correct, then Zenamour should be tasked with cleaning up
after their product is removed or updated.

/local/lib/php/20200930/mongodb.so.so (Cannot open "/usr/local/lib/php/20200930/mongodb.so.so")) in Unknown on line 0
[06-Aug-2022 08:25:45 UTC] PHP Warning:  PHP Startup: Unable to load dynamic library 'mongodb.so' (tried: /usr/local/lib/php/20200930/mongodb.so (Cannot open "/usr/local/lib/php/20200930/mongodb.so"), /usr/local/lib/php/20200930/mongodb.so.so (Cannot open "/usr/local/lib/php/20200930/mongodb.so.so")) in Unknown on line 0

Getting these since upgrade to 22.7_4-amd64 05-Aug-2022.
Report has been raised and sent, also a post in the German section
https://forum.opnsense.org/index.php?topic=29717.msg143542#msg143542
appears to have a similiar issue.
Zenamor was removed a few weeks ago and not reinstalled.
Is mongodb used anywhere else?
All other processes are function correctly as far as I can tell.

Re netflow, I am using V5 sent from opnsense using graylog netflow input, port 2055.
Using the show received message, they are readable

Re the hostname of internal ip addresses, I don't know if they are included in the syslog message any where, I have never seen them.
I use the syslog messages, sent on a different port, (see earlier post). To get the reverse dns I use the graylog reverse dns input then in the pipeline the rule I showed earlier. I assume it uses the local dns server to get the internal host names, I use unbound, and the internal hostnames are set up there.

RE maxmind (other files are available), they are never going to be 100% accurate or complete.

Re Reverse dns for external addresses, some organisations do not provide the hostname

[let lv = lookup_value(lookup_table:"reverse_dns", key:ts);]

This is the rule I use in the pipe for trapping firewall blocks

rule "Reverse Dns: Firewall src_ip"
when

has_field("src_ip") && is_not_null("src_ip")

then
// Declare a variable that will pull the value from
// the source address field for use in the lookup.
let ts = to_string($message.src_ip);

// Declare a variable that looks up the value stored in the
// lookup table specified matching the value found in the previous variable.
let lv = lookup_value(lookup_table:"reverse_dns", key:ts);

// Set field with name specified and value returned from the previous lookup.
set_field("src_hostname", lv);

You will need a lookup table to do the reverse dns from the ip address.
let lv = lookup_value(lookup_table:"reverse_dns", key:ts);

BTW, you may eventually be using GeoIP databases (MaxMind and others are available!!) to get geospatial data,
the source ip (src_ip) used is confusing, and really should be the search_ip (ie could be a source or destination ip depending on what you are doing)

Also in your post there is a reference to influxdb, there is an graylog output to influxdb V1, which is not the latest, its now V2, its access and query mechanism has changed considerably. It is possible to use a V1 connection with the old query mechanism, it is documented on the influxdb page, it does work, though one expects it to disappear in the future, so all my influxdb's are V2

[message must contain block]

I never used the Docker approach, to me its another level of complexity, I just installed graylog, elastic on a vm.
In opensense I filtered the firewall, see attached. Note the port used, this allows for simple routing to graylog, so the input must use the same port/protocol
Inputs do not use any extractors, Streams have a simple filter , for firewall its

message must contain block

Then its on to pipelines, more fun  :)

The src_ip is a bit misleading.
Here is my rule in the pipeline


rule "GeoIP City: src_ip"
when
has_field("src_ip") && is_not_null("src_ip")
then
let geo = lookup("mm-city", to_string($message."src_ip"));
set_field("src_ip_geo_location", geo["coordinates"]);
set_field("src_ip_geo_country", geo["country"].iso_code);
set_field("src_ip_geo_city", geo["city"].names.en);
end


I used lookup tables to resolve the MaxMind (and other mmdb's) to get the geospatial info, not sure if its correct with grafana's map though (it appears to have its own lookup based on country codes) , and the new grafana map needs geohashes (not available from graylog afaik), however the grafana table is getting the data from the elasticsearch indices.

I am unsure if I have got it all efficient and correct (graylog), but its a better solution than logstash.

I have opnsense sending logs, trapped for the firewall monitor (using grafana table & map)
In addition I have netflow V5 feeding flows to graylog for monitoring (using grafana table & map)
Suricata is still on the naughty step for causing issues, maybe with the wan interface.
Graylog is a bit of a learning curve.
Elastic search is the database (boo hoo as I prefer TIKS but couldnt find a working solution).
The impact on opnsense is minimal, all the processing performed on a VM, so opnsense is just the sender.
I did have an issue with opensense's  netflow aggregator process, racking lots of cpu, so I managed to disable it, its not needed as I have my pretty grafana graphs.

I noticed this while setting up my new netflow collector (remote), and I shutdown the flowd_aggregate service via the gui ( I expect there is a place to disable it, please do tell!!)

I sincerely suggest that the official should do enough testing before considering whether to release it as a production version.
Switching to Ver 13 brings with it the sheer number of issues it's daunting. Let me keep the good OPNsense 21.7.8-amd64 until 22.7 comes along.
But I also see good news, the official hardware 850 is finally in stock. ;D

A system like opnsense is extremely complicated, and is subject to issues within the underlying operating system, of which opnsense have no control.

My installation to the latest version has been quite good, the only issue is suricata dropping the wan, but yet again, suricata is not under the control of the opnsense team.

My upgrade down time was less than one hour.

Like any free (or did you pay ?) software is always tested by the user (actually even purchased software is by definition always beta, as there will always be issues)

Opnsense is designed to protect your network, which is under attact from many sources.

Please advise if you can find a better option, perhaps a Faraday cage with no external connections?

Is your UPS on the list
https://networkupstools.org/stable-hcl.html

also
  0.018140     Trying megatec protocol...
   0.019889     send: Q1
   0.250438     read: (232.9 232.9 232.9 007 50.1 13.5 25.0 00001001
   0.250576     Status read in 1 tries
   0.250595     Supported UPS detected with megatec protocol

Is this significant, its not on the drop down list of drivers in opnsense

Also
https://networkupstools.org/protocols/megatec.html
may be relavent
Finally
https://networkupstools.org/index.html
may help
and
searching
https://github.com/networkupstools/nut/search?q=megatec
may also through up some ideas.

I never had to change anything internal for my UPS, it just worked.
Apologies if I missed something, but what model is your UPS?

[Bug-fix: OPNsense UI: Fixed Safari browser compatibility issue]

Finally Engine update 1.11.1 fixes the issue with Safari, for me anyway.
Perhaps better pre release testing should take priority over New Features.


Zenconsole

New Feature: Cloud Portal: New payment method: WeChat Pay
New Feature: Cloud Central Management: Ability to share firewalls with free edition or home subscription
Bug-fix: Live Session Explorer: Fixed drill-down according to MAC addresses
Bug-fix: OPNsense UI: Fixed Safari browser compatibility issue
Bug-fix: OPNsense UI: Fixed backup compatibility issue with early versions

My aliases are available, however they are not apparent on the unbound page which has a changed layout.
They are also in the json file produced prior to the upgrade, so all is not (unless you have no local backups)