Messages

OK, again a very good point. So now i think i got the final idea. Again learned a lot!
Thanks again for your fast help and such a good lession about setting up things easy and secure to external changes (DHCP-changes in our case)

Thanks a lot for your advise!
I tried your settings but was out of luck first, but finally got it: I had to enter the real IP of my opnsense in NUT -> general information and usbhid as the local device.
The port forwarding wasnt necessary (both devices are in the same lan-segment). Or am i missing again something?
So now i see the UPS-status on OPNsense and my NAS is showing the status of the remote UPS too.

The only caveat now is that we dont have a NUT-widget for the dashboard...

Same here, i am impressed of the big changes regarding the dashboard!
Thanks to all for your great work!

I am using the apcupsd for the UPS which is connected via USB to OPNsense. I have configured the NUT service to offer the UPS to my NAS (Xigmanas), which is using NUT as UPS-tool.
So far, the service works as expected, both OPNsense and Xigmanas show the UPS as living and working. But when i restart OPNsense the NUT service is the only service which doesnt start up, even when i wait more time for the system to get settled.
Eventually i am missing something to get the NUT start up?

Logs show this:

entry after starting NUT manually:
2024-08-08T16:02:07   Warning   upsd   /usr/local/etc/nut/upsd.users is world readable   
2024-08-08T16:02:07   Warning   upsd   /usr/local/etc/nut/upsd.conf is world readable

Logs after reboot show many entries of this:   
2024-08-08T16:02:02   Error   upsmon   UPS [usv]: connect failed: Connection failure: Connection refused

One idea, based on your HW-probe:

Probe tells about BIOS:
SYS   dell-6-4-0-07-23-2013 »   Dell Inc.   BIOS 6.4.0 07/23/2013   bios

Dell Site has a BIOS-Update for the T710:
https://www.dell.com/support/home/de-de/product-support/product/poweredge-t710/drivers.

Sounds to me like (maybe) a BIOS-problem...

I had problems with FTDI-Adapters, Adapters with PL2303-Chip (RS232) worked directly without problems...
https://www.prolific.com.tw/US/ShowProduct.aspx?pcid=41&showlevel=0017-0037-0041

Otherwise try an adapter for RS232. (I mostly needed to install a driver, which doesnt exist for Freebsd)
https://ftdichip.com/product-category/products/cables/

But i dont know if they are supported now with Freebsd 13/14.

Buyah! What a great thing! I am impressed again! Thanks a lot for your great work!!!
Wish you all a great weekend (and the following times)

What a fast answer! Now my hopefully not too silly question: How do i get that? I tried via "opnsense-revert -z os-ddclient" (found in another thread, only for different package), but its still the "old" one.
Or do i have to wait for the next release?
Thanks a lot!!!!

Not only the network-time widget, i am missing the UPS-widget too. Hopefully the widgets from the previous version will come back soon...
By the way, a Dyndns-widget would be nice!

At all, the new version made me happy, some annoying glitches are finally gone, which i had with the 24.3.
Such a big changes with the dashboard show me there is a highly active work in progress!
Regarding pfsense, i changed because with the change of their business-model things got mad, long time there were big problems with updates and other things, not to forget the "fiasco" with wireguard, which made the whole thing really unsecure.
I am happy with a firewall which is "made in europe", i feel more comfortable here with OPNsense. I see that american ways of doing software is so different to european way. We need more software like this!

I encountered a constant communication failure in conjunction with the latest Nextcloud v29 and after fiddling some days i found a solution which made the service work.

Failures were like "Error while fetching filelist from Nextcloud '/.' path", "Cannot get real username", "cannot execute MKCOL"

So the first thing was the annoying "Setup Cache..." inside Nextcloud Administration...
I decided to install redis to get rid of that messages.
And finally this resulted in a working Backup!
But! again some strange things happened...
I installed the corresponding php83-pecl-redis Extension to access Redis,
configured redis to use socket,
secured redis with Auth-password (i am a bit paranoid).
To create the auth-password there are some tips around the world, but the only working password-creation which worked was:

Code Select Expand

openssl rand 60 | openssl base64 -A
Changed the corresponding files (config.php of Nectcloud) and redis.conf.
Most important step was adding user www (or www-data), depending of the used server.
Tested:

Code Select Expand

sudo -u www redis-cli -s /var/run/redis/redis.sock ping
(error) NOAUTH Authentication required.
again by passing the password:

Code Select Expand

sudo -u www redis-cli -s /var/run/redis/redis.sock -a openssl-created-password ping
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
PONG
At this moment the configuration of Nextcloud-Backup from OPNsense didnt throw out any more errors and its working as expected!
It "should" work without password, but in my case it didnt. Maybe its because of the redis.conf entry
"protected-mode yes" which i didnt want to change.
Hopefully that helps others to get it working!

I am having a really strange error whit my nextcloud-backup:

Code Select Expand

2024-07-09T08:44:40 Error config {"url":"https:\/\/nas.xxx.xyz:8443\/nextcloud\/remote.php\/dav\/files\/opnsense\/OPNsense-Backup","content_type":null,"http_code":0,"header_size":0,"request_size":0,"filetime":-1,"ssl_verify_result":0,"redirect_count":0,"total_time":60.034358,"namelookup_time":0.001119,"connect_time":0,"pretransfer_time":0,"size_upload":0,"size_download":0,"speed_download":0,"speed_upload":0,"download_content_length":-1,"upload_content_length":-1,"starttransfer_time":0,"redirect_time":0,"redirect_url":"","primary_ip":"","certinfo":[],"primary_port":0,"local_ip":"","local_port":0,"http_version":0,"protocol":0,"ssl_verifyresult":0,"scheme":"","appconnect_time_us":0,"connect_time_us":0,"namelookup_time_us":1119,"pretransfer_time_us":0,"redirect_time_us":0,"starttransfer_time_us":0,"total_time_us":60034358,"effective_method":"MKCOL"}
2024-07-09T08:44:40 Error config cannot execute MKCOL

My nextcloud is sitting on a xigmanas, certs are generated from opnsense, the nas shows cert is ok, valid and trusted (self signed) -> "http_code":0 and "ssl_verifyresult":0.
But what i dont understand is the MKCOL-error. Searching the net doesnt show up relevant infos...
My opnsense is the latest (OPNsense 24.1.9_4-amd64). Same with my xigmanas, nextcloud is 29.0.3.
There are no errors in my nextcloud installation, i generated the App-password for use with the opnsense-backup.

Any help would be great!

I think, i found the problem:
The last entry of the wireguard log shows "#define WITH_DEFAULT_IPV 4"; due to whatever reason my dyndns-provider ddnss.de only propagates IPv6-Address, even with the IPv4 availability.
The ddclient of opnsense shows both IPv4 and IPv6 addresses.
A DNS-test revealed that only the IPv6 is available at different DNS-servers.

So my question is: Exists the option to remove that DEFAULT_IPV 4? Or set it to IPv6? I have seen that there is an option on acme.sh "--listen-v6"...
Or will you add the relevant option to the settings?
Thank you very much!

By the way: Renewal of cert fails with both options, Test-CA and Default CA.

Hello again,
yesterday i noticed that my acme certs failed to renew:

/usr/local/opnsense/scripts/OPNsense/AcmeClient/lecert.php: AcmeClient: The shell command returned exit code '1': '/usr/local/sbin/acme.sh --renew --syslog 9 --debug 3 --server 'letsencrypt' --dns 'dns_ddnss' --home '/var/etc/acme-client/home' --cert-home '/var/etc/acme-client/cert-home/yyyy.21871376' --certpath '/var/etc/acme-client/certs/yyyy.21871376/cert.pem' --keypath '/var/etc/acme-client/keys/yyyy.21871376/private.key' --capath '/var/etc/acme-client/certs/yyyy.21871376/chain.pem' --fullchainpath '/var/etc/acme-client/certs/yyyy.21871376/fullchain.pem' --domain '*.domain.ddnss.de' --days '1' --keylength 'ec-384' --ecc --accountconf '/var/etc/acme-client/accounts/xxxx.93537913_prod/account.conf''

The cert was successfully created/renewed on April, the only change was the latest update of opnsense (and the prevoious updates), i didnt change any of the acme settings...

On earlier run i had an exit code 2, so i removed the OSCP staple setting:
/usr/local/opnsense/scripts/OPNsense/AcmeClient/lecert.php: AcmeClient: The shell command returned exit code '2': '/usr/local/sbin/acme.sh --renew --syslog 9 --debug 3 --server 'letsencrypt' --dns 'dns_ddnss' --home '/var/etc/acme-client/home' --cert-home '/var/etc/acme-client/cert-home/yyyy.21871376' --certpath '/var/etc/acme-client/certs/yyyy.21871376/cert.pem' --keypath '/var/etc/acme-client/keys/yyyy.21871376/private.key' --capath '/var/etc/acme-client/certs/yyyy.21871376/chain.pem' --fullchainpath '/var/etc/acme-client/certs/yyyy.21871376/fullchain.pem' --domain '*.igorius.ddnss.de' --days '1' --ocsp --keylength 'ec-384' --ecc --accountconf '/var/etc/acme-client/accounts/xxxx.93537913_prod/account.conf''

The txt-record gets written on ddnss.de, but the verification afterwards fails.
At the moment i have to wait a week, i think that 5 tries are reached.
Has anyone else seen that errors?

Since 424.1 and with 24.1.1 OpenVPN doesnt start automatically, i have to restart the daemon manually.
The log doesnt show anything regarding a failure or anythig else. Only notices about reconfiguring and syncing.

Code Select Expand

2024-02-09T14:34:47 Notice opnsense /usr/local/etc/rc.newwanip: Resyncing OpenVPN instances for interface OVPN.
2024-02-09T14:34:47 Notice opnsense /usr/local/etc/rc.newwanip: plugins_configure vpn (execute task : openvpn_configure_do(,opt1))
2024-02-09T01:30:27 Notice opnsense /usr/local/etc/rc.newwanipv6: Resyncing OpenVPN instances for interface LAN.
2024-02-09T01:30:27 Notice opnsense /usr/local/etc/rc.newwanipv6: plugins_configure vpn (execute task : openvpn_configure_do(,lan))
2024-02-09T01:30:09 Notice opnsense /usr/local/etc/rc.newwanipv6: Resyncing OpenVPN instances for interface WAN.
2024-02-09T01:30:09 Notice opnsense /usr/local/etc/rc.newwanipv6: plugins_configure vpn (execute task : openvpn_configure_do(,wan))
2024-02-09T01:29:29 Notice opnsense /usr/local/etc/rc.newwanip: Resyncing OpenVPN instances for interface WAN.
2024-02-09T01:29:29 Notice opnsense /usr/local/etc/rc.newwanip: plugins_configure vpn (execute task : openvpn_configure_do(,wan))
2024-02-09T01:29:18 Notice opnsense /usr/local/etc/rc.newwanip: Resyncing OpenVPN instances for interface WAN.
2024-02-09T01:29:18 Notice opnsense /usr/local/etc/rc.newwanip: plugins_configure vpn (execute task : openvpn_configure_do(,wan))
2024-02-09T01:28:05 Notice opnsense /usr/local/etc/rc.newwanipv6: Resyncing OpenVPN instances for interface LAN.
2024-02-09T01:28:05 Notice opnsense /usr/local/etc/rc.newwanipv6: plugins_configure vpn (execute task : openvpn_configure_do(,lan))
2024-02-09T01:27:49 Notice opnsense /usr/local/sbin/pluginctl: plugins_configure crl (execute task : openvpn_refresh_crls(1))
2024-02-09T01:27:49 Notice kernel <118>>>> Invoking start script 'openvpn'

After upgrading to 24.1 and 24.1_1 i encountred a strange problem with the ntpd:
Sometimes i got answers from the public servers, time got synced (Sync Source   2001:638:610:be (stratum 1, .PTB.)
But sometimes there was no sync. Looking at the logs i saw

Code Select Expand

2024-02-10T11:53:08 Informational ntpd failed to init interface for address fd00::225:90ff:fea8:83
2024-02-10T11:53:08 Error ntpd unable to create socket on em0 (7) for fd00::225:90ff:fea8:83#123
2024-02-10T11:53:08 Error ntpd bind(25) AF_INET6 fd00::225:90ff:fea8:83#123 flags 0x11 failed: Address already in use
2024-02-10T11:53:08 Informational ntpd failed to init interface for address fe80::225:90ff:fea8:83%1
2024-02-10T11:53:08 Error ntpd unable to create socket on em0 (6) for fe80::225:90ff:fea8:83%1#123
2024-02-10T11:53:08 Error ntpd bind(25) AF_INET6 fe80::225:90ff:fea8:83%1#123 flags 0x11 failed: Address already in use

So i stopped the daemon and realized that it was started twice: Had to stop it 2 times via the Stop-button.
After stopping and waiting a moment, i started it again and it works again and syncs.