Messages

Finally, the issue occured again.  :'(
Interestingly, only one relay seemed to have these issues, but in the end I stopped to investigate and gave up. I migrated the DHCP task to the OPNsense, hoping that my OPNsense becomes as stable and reliable as it was before.

Cheers,
WM54

Just want to share an observation from my side:

I tried to revert to 24.1.5, but this did not work, so I decided to do a fresh install of 24.1, upgrade this to 24.1.5. and restore my config afterwards. But after having installed 24.1 the installation of the needed plugins was not possible - I received the message that my installation is outdatet and the installation of 24.1.6 is required. So I was forced to upgrade to 24.1.6. again :-( So I did the upgrade and restored my configuration.

And surprisingly, since the fresh install I had no issues until now. Crossing fingers, that this behaviour remains! :-)

If the current status remains and no further issues occur, I would assume, that the problem could be a result of a malfunction in the upgrade process of my previous installation  to 24.1.6.

Let's see what happens in the next few days! :-)

Thanks for the hint - opened new thread.

Regards,
WM54

Dear Forum members,

I am facing DHCP relay issues since updated to 24.1.6 - in earlier versions all worked as expected and I observed no issues.

Currently it seems that the DHCP relays suddenly stop to work and the clients are not longer able to receive DHCP addresses or renew the lease. Until lease expiry, the clients work as expected, but when the has expired, they are disconnected.
Also I am observing "BAD_ADDRESS" entries in the DHCP server, which I didn't notice before.

In some cases a restart of the DHCP relays solves the issue for some time, but not in every case.
Any suggestions if it is possible to log the activity of the relays? I did not find a regarding log yet.

I am using three DHCP relays to forward the DHCP requests of three subnets to one central DHCP server.
OPNsense is vitualized based on ESXi hypervisor - each OPNsense subnet uses its own virtual NIC  provided by ESXi.

Any hints, how to enclose the issue are highly appreciated.
Many thanks in advance!

Best regards,
WM54

Unfortunately I am also facing DHCP relay issues since updated to 24.1.6 - in earlier versions all worked as expected and I observed no issues.

Currently it seems that the DHCP relays suddenly stop to work and the clients are not longer able to receive DHCP addresses or renew the lease. Until lease expiry, the clients work as expected, but when the has expired, they are disconnected.
Also I am observing "BAD_ADDRESS" entries in the DHCP server, which I didn't notice before.

In some cases a restart of the DHCP relays solves the issue for some time, but not in every case.
Any suggestions if it is possible to log the activity of the relays? I did not find a regarding log yet.

I am using three DHCP relays to forward the DHCP requests of three subnets to one central DHCP server.
OPNsense is vitualized based on ESXi hypervisor - each OPNsense subnet uses its own virtual NIC  provided by ESXi.

Any hints, how to enclose the issue are highly appreciated.
Many thanks in advance!

Best regards,
WM54

Thank you very much - this solved my issue!

After solving the freezing issue by adding more RAM, I am now stuggling with the next issue :-(
The CLAMAV service is stopping without any (for me) visible error or log entry.
The dashboard shows the stopped service - when strating it with the start button, it starts and seems to work, but next day the service is stopped again.

Does anyone have a idea how to analyze and solve this?

Many thanks in advance,
WM54

Thank you for your response!
Well the transparent proxy is the reason why I want to use clamav.

Anyway - it sems that it was (as in most cases) a layer 8 problem! ::)
I resolved the "problem" by adding more RAM to the machine an one more CPU core.
With tat in place, it runs ...

Hi all,

I'm struggling with a very similar behaviour of my fresh installed OPNsense 20.1.8 installed virtualized on ESXi 6.5.
Although there is a very low CPU load, the systems seems to be frozen after activating the clamAV Service. No more interaction possible - no webGUI, no ssh terminla, no reaction to local console, the only thing, the box does, is responding to the ping request, I sent to it.

The mystery started with trying to download the signatures before enabling the servie as stated in the banner abov the configuration section. This resulted in the first freeze an ended in recovering a backup configuration via local console in single user mode.
After that I tried several deinstallations and reinstallations of the clamAV Plugin, but after enabling the service it ended in a frozen system.
Lastly I gave a try to downloading the signatures manually and uploading them to /var/db/clamav/ - the sigatures were correctly recognized, but the raction to enabling the service was the same - next freeze.

The clamAV log file looks like this:

Code Select Expand

Thu Jul 16 21:22:15 2020 -> Update process terminated
Thu Jul 16 19:44:48 2020 -> --------------------------------------
Thu Jul 16 19:44:48 2020 -> bytecode.cvd database is up to date (version: 331, sigs: 94, f-level: 63, builder: anvilleg)
Thu Jul 16 19:44:48 2020 -> main.cvd database is up to date (version: 59, sigs: 4564902, f-level: 60, builder: sigmgr)
Thu Jul 16 19:44:48 2020 -> daily.cvd database is up to date (version: 25875, sigs: 3437957, f-level: 63, builder: raynman)
Thu Jul 16 19:44:48 2020 -> ClamAV update process started at Thu Jul 16 19:44:48 2020
Thu Jul 16 19:44:48 2020 -> Received signal: wake up
Thu Jul 16 17:44:48 2020 -> --------------------------------------
Thu Jul 16 17:44:48 2020 -> bytecode.cvd database is up to date (version: 331, sigs: 94, f-level: 63, builder: anvilleg)
Thu Jul 16 17:44:48 2020 -> main.cvd database is up to date (version: 59, sigs: 4564902, f-level: 60, builder: sigmgr)
Thu Jul 16 17:44:48 2020 -> daily.cvd database is up to date (version: 25875, sigs: 3437957, f-level: 63, builder: raynman)
Thu Jul 16 17:44:48 2020 -> ClamAV update process started at Thu Jul 16 17:44:48 2020
Thu Jul 16 17:44:48 2020 -> freshclam daemon 0.102.3 (OS: freebsd11.2, ARCH: amd64, CPU: amd64)
Thu Jul 16 17:44:47 2020 -> --------------------------------------

The termination entry in the Log is the result of switching off the system.

I have no more ideas! Is there anybody out there, who could give a OPNsense newbie (coming from several years with Astaro, Sophos UTM and OpenWRT) a hint? Any help or hint is greatly appreciated!

Many thanks in advance,
WM54