Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Topics - pbk

#1
Hi there,

here's an issue which seems related to 25.7.8. If the Pulseway RMM (or Kaseya VSA) is installed on an OPNsense system, it'll fail starting the service on boot up. Service is started by rc.conf.

25.7.8 was installed on one system only so far.


<13>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain kernel - - [meta sequenceId="324"] <118>[26] Starting pulseway.
<13>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain root 73890 - [meta sequenceId="325"] /usr/sbin/service: WARNING: $mpd_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain root 78128 - [meta sequenceId="326"] /usr/sbin/service: WARNING: $dhcp6c_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain kernel - - [meta sequenceId="327"] <118>[26] Starting lldpd.
<13>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain kernel - - [meta sequenceId="328"] <118>[26] pulseway already running?  (pid=22825).
<13>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain kernel - - [meta sequenceId="329"] <118>[26] >>> Invoking start script 'syslog'
<13>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain kernel - - [meta sequenceId="330"] <118>[26] >>> Invoking start script 'xen'
<13>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain kernel - - [meta sequenceId="331"] <118>[26] Starting xenguest.
<13>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain kernel - - [meta sequenceId="332"] <118>[27] >>> Invoking start script 'carp'
<13>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain kernel - - [meta sequenceId="333"] <118>[27] >>> Invoking start script 'cron'
<13>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain root 90361 - [meta sequenceId="334"] /usr/sbin/service: WARNING: $unbound_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain root 93123 - [meta sequenceId="335"] /usr/sbin/service: WARNING: $radvd_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain root 37088 - [meta sequenceId="336"] /usr/sbin/service: WARNING: $configd_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain root 49328 - [meta sequenceId="337"] /usr/sbin/service: WARNING: $openvpn_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain root 50789 - [meta sequenceId="338"] /usr/sbin/service: WARNING: $openssh_enable is not set properly - see rc.conf(5).
<45>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain syslog-ng 13690 - [meta sequenceId="1"] Configuration reload request received, reloading configuration;
<45>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain syslog-ng 13690 - [meta sequenceId="2"] Configuration reload finished;
<13>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain root 59564 - [meta sequenceId="3"] /usr/sbin/service: WARNING: $dhcpd_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain root 61028 - [meta sequenceId="4"] /usr/sbin/service: WARNING: $dhcpd6_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain root 62616 - [meta sequenceId="5"] /usr/sbin/service: WARNING: $strongswan_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain root 65911 - [meta sequenceId="6"] /usr/sbin/service: WARNING: $snmptrapd_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain root 67926 - [meta sequenceId="7"] /usr/sbin/service: WARNING: $snmpd_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain root 70971 - [meta sequenceId="8"] /usr/sbin/service: WARNING: $rrdcached_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain root 83400 - [meta sequenceId="9"] /usr/sbin/service: WARNING: $kpropd_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain root 86704 - [meta sequenceId="10"] /usr/sbin/service: WARNING: $samplicator_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain root 88919 - [meta sequenceId="11"] /usr/sbin/service: WARNING: $xenguest_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain root 91219 - [meta sequenceId="12"] /usr/sbin/service: WARNING: $choparp_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain root 93550 - [meta sequenceId="13"] /usr/sbin/service: WARNING: $lighttpd_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain root 97460 - [meta sequenceId="14"] /usr/sbin/service: WARNING: $php_fpm_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain kernel - - [meta sequenceId="15"] OK
<13>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain root 39706 - [meta sequenceId="16"] /usr/sbin/service: WARNING: $mpd_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain root 42364 - [meta sequenceId="17"] /usr/sbin/service: WARNING: $dhcp6c_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain root 55528 - [meta sequenceId="18"] /usr/sbin/service: WARNING: $unbound_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain root 57465 - [meta sequenceId="19"] /usr/sbin/service: WARNING: $radvd_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain opnsense 59989 - [meta sequenceId="20"] /usr/local/sbin/pluginctl: plugins_configure crl (1)
<13>1 2025-11-28T16:33:26+01:00 OPNsensePlayground.localdomain opnsense 59989 - [meta sequenceId="21"] /usr/local/sbin/pluginctl: plugins_configure crl (execute task : core_trust_crl(1))
<13>1 2025-11-28T16:33:27+01:00 OPNsensePlayground.localdomain root 84561 - [meta sequenceId="22"] /usr/sbin/service: WARNING: $configd_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:27+01:00 OPNsensePlayground.localdomain root 93146 - [meta sequenceId="23"] /usr/sbin/service: WARNING: $openvpn_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:27+01:00 OPNsensePlayground.localdomain root 95159 - [meta sequenceId="24"] /usr/sbin/service: WARNING: $openssh_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:27+01:00 OPNsensePlayground.localdomain root 1440 - [meta sequenceId="25"] /usr/sbin/service: WARNING: $dhcpd_enable is not set properly - see rc.conf(5).
<12>1 2025-11-28T16:33:27+01:00 OPNsensePlayground.localdomain opnsense 59903 - [meta sequenceId="26"] /usr/local/sbin/pluginctl: warning: ignoring missing default tunable request: vm.pmap.pti
<12>1 2025-11-28T16:33:27+01:00 OPNsensePlayground.localdomain opnsense 59903 - [meta sequenceId="27"] /usr/local/sbin/pluginctl: warning: ignoring missing default tunable request: hw.ibrs_disable
<13>1 2025-11-28T16:33:27+01:00 OPNsensePlayground.localdomain root 3069 - [meta sequenceId="28"] /usr/sbin/service: WARNING: $dhcpd6_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:27+01:00 OPNsensePlayground.localdomain root 5221 - [meta sequenceId="29"] /usr/sbin/service: WARNING: $strongswan_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:27+01:00 OPNsensePlayground.localdomain root 7231 - [meta sequenceId="30"] /usr/sbin/service: WARNING: $snmptrapd_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:27+01:00 OPNsensePlayground.localdomain root 9190 - [meta sequenceId="31"] /usr/sbin/service: WARNING: $snmpd_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:27+01:00 OPNsensePlayground.localdomain root 11137 - [meta sequenceId="32"] /usr/sbin/service: WARNING: $rrdcached_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:27+01:00 OPNsensePlayground.localdomain kernel - - [meta sequenceId="33"] <118>[27] >>> Invoking start script 'openvpn'
<13>1 2025-11-28T16:33:27+01:00 OPNsensePlayground.localdomain kernel - - [meta sequenceId="34"] <118>[27] >>> Invoking start script 'sysctl'
<13>1 2025-11-28T16:33:27+01:00 OPNsensePlayground.localdomain opnsense 59989 - [meta sequenceId="35"] /usr/local/sbin/pluginctl: plugins_configure crl (execute task : openvpn_refresh_crls(1))
<13>1 2025-11-28T16:33:27+01:00 OPNsensePlayground.localdomain root 21310 - [meta sequenceId="36"] /usr/sbin/service: WARNING: $kpropd_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:27+01:00 OPNsensePlayground.localdomain root 22332 - [meta sequenceId="37"] /usr/sbin/service: WARNING: $samplicator_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:27+01:00 OPNsensePlayground.localdomain root 23532 - [meta sequenceId="38"] /usr/sbin/service: WARNING: $xenguest_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:27+01:00 OPNsensePlayground.localdomain root 24823 - [meta sequenceId="39"] /usr/sbin/service: WARNING: $choparp_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:27+01:00 OPNsensePlayground.localdomain root 26010 - [meta sequenceId="40"] /usr/sbin/service: WARNING: $lighttpd_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:27+01:00 OPNsensePlayground.localdomain root 27649 - [meta sequenceId="41"] /usr/sbin/service: WARNING: $php_fpm_enable is not set properly - see rc.conf(5).
<13>1 2025-11-28T16:33:27+01:00 OPNsensePlayground.localdomain kernel - - [meta sequenceId="42"] <118>[27] Service `sysctl' has been restarted.
<13>1 2025-11-28T16:33:27+01:00 OPNsensePlayground.localdomain kernel - - [meta sequenceId="43"] <118>[27] >>> Invoking start script 'beep'
<11>1 2025-11-28T16:33:27+01:00 OPNsensePlayground.localdomain pulsewayd 22825 - [meta sequenceId="44"] Signal handled: 11
<13>1 2025-11-28T16:33:27+01:00 OPNsensePlayground.localdomain kernel - - [meta sequenceId="45"] <6>[28] pid 22825 (pulsewayd), jid 0, uid 0: exited on signal 11 (no core dump - bad address)

If the Pulseway service is started after OPNsense is fully stated up, it starts and runs:

root@OPNsensePlayground:~ # service pulseway start
Starting pulseway.
root@OPNsensePlayground:~ # service pulseway status
pulseway is running as pid 77088.


If the system is reverted back to 25.7.7_4, everything works again and the service is started during boot up.


I'm posting it here because it might not be Pulseway's fault because the service does start fine manually. And the release notes for 28.7.8 said we should report weird behaviour which might be related to the newer kernel.
#2
Deleting a revocation under "System: Trust: Revocation" trows error "Endpoint not found". Happens in 24.7_x and 24.7.1.

Certs have been revoked sometimes with 24.1 or 23.x – so it might be something that happens to older entries only. Have no newer revocations.
#3
Hi!

Maybe I'm mistaken but... Sending a request to API endpoint kea/dhcpv4/getSubnet responds with subnet details like DNS servers, routers and NTP. But the subnets configured are not part of the response.

I guess the field "subnet" should contain the CIDR, but it doesn't.

Not sure if this is a known issue, I couldn't find anything in the forum.

Screenshots attached.

OPNsense version is 24.1.2_1

And a small addition: the pools section is empty, too. And if there are more than one subnet defined, only the first one is in the API response.
#4
After each reboot of a client, Kea does see that the system did reboot and that it tries to get its lease back. So far so good.

But each of these result in a new lease (for the same IP and MAC) being shown in the Leases DHCPv4 section.

Screenshots attached.

Is that expected behaviour?
#5
This is a weird issue and I'm watching this happening for some time now.

Attached is a screenshot from the DHCP log. You can see that the server is giving a DHCPACK for a client asking for reusing an issued IP sometimes in the past.

Next screenshot is the static IP section from the corresponding DHCP. As you can see, the same IP is set as static for a different MAC.

This should never happen.

What I was able to observe is this:
- If a client is receiving a dynamic lease for an ip and then is switched off and (even if the lease is removed) then...
- this IP is made static for a different device...
- OPNsense is accepting the lease request from the client requesting the renewal of the lease it was given some time ago

This seems happening if this specific scenario occurs. Rebooting OPNsense will not fix it. Deleting the dynamic lease will not fix it. Actively making the client release the ip and request a new one is the only way to fix it. But this should be DHCP servers job. It seems as if the OPNsense DHCP is just not checking what IPs are set to static when receiving a renewal request.

The third screenshot is the leases view with the static and the wrongly leased dynamic IP. The moment the address is handed out as dynamic, the shown status for the device with the static IP will switch from online to offline. But take this with a grain of salt – the online/offline status is nothing reliable and can change erratically.

Version 23.7.11
#6
Hi guys,

this is something bugging me for some time now, I guess is startet with upgrading from 23.7.2 to .3 and is happening ever since.

Every few hours (sometimes it works for up to two days) the dnsbl_module is losing its backend. Unbound then still resolves domain names but the whole blocklist filtering stops. I'm not 100% sure since when it startet because nobody checks the unbound graph all the time.

[76481:1] info: dnsbl_module: Logging backend closed
connection. Closing pipe and continuing.
[76481:2] info: dnsbl_module: attempting to open pipe
[76481:2] info: dnsbl_module: no logging backend found.


Restarting Unbound resolves the issue for a few hours. It'll never resolve on its own.

I was unable to find some kind of a scheme happening, I first thought it could be because too many SERVFAILs, but that was a red herring. I then thought it might happen after many hours of not logging anything to the Unbound log, but that's not the case.
I've been unable to duplicate that behaviour in a VM, but that might be related to nothing being blocklisted on this VM-Net. All other OPNsenses I'm dealing with are still on 23.1 so I have nothing to compare it to.

The only "solution" is to restart unbound every three hours by cron – which is a full blown redneck solution.

I've attached two unbound log screenshots and the corresponding unbound reporting graph (the are a tad small, because limits).
#7
If the Web GUI ist set to listen to an ZeroTier Interface, it's no longer listening to that interface after a reboot. This did work prior to 23.1.6 so I suppose it's somewhat related.

Here's how to reproduce:


  • Connect OPNsense to a ZeroTier network
  • Add the ZT interface to the listen interface for the Web GUI (I don't know if it will fail if set to all, but just use something like LAN and the ZT interface to simplify things)
  • Create a Firewall rule for the ZT interface to allow connections from the ZT network to this firewall for port 443
  • Connect a second device to the ZT network and check if the Web GUI is accessible via its ZT IP

If everything works, reboot the firewall.

Try to reconnect after everything is back up and running.

The connection will fail and results in syn closed.

Now do the following:


  • Go to System->Settings->Administration and remove the ZT interface from the listen interfaces
  • Save the settings and wait for the UI to reload
  • Add the ZT interfacce back to the listen interfaces, save and wait for the reload

The Web GUI is accessible again using the ZT IP.

This weird behaviour did show up after updating to 23.1.6. Rebooting did not cause the system to fail in the previous firmware release.