Messages

Thank you for the response.
I will keep monitoring the situation.
Still my best guess would be the missing restart of the OpenVPN server instances.
We have around 30 connections every day and did not run into such issue before.

Still you are right. The DCO is not active for such a long time.

So fingers crossed that this was a one time event.

OK understood.
I will keep monitoring it.

So you don't think that the missing restart to the service after the update could not be the root cause?

Hi Franco,

thank you very much for the reply.

DCO is running since 21st of January 2026 on our instance without such a crash.

I noticed with the update from 26.1.1 to 26.1.2 the IP assignment from the VPN was not reset like it is happening after a reboot of the OPNsense.
I just checked the logs and I would say the OpenVPN server have not been restarted during the update. Even so there was the update to OpenVPN 2.6.19.

I could imagine that this could cause such strange issues.

Hi all,

I have updated our OPNsense to 26.1.2 yesterday.
Today it went into a crash and a automatic reboot.

I would like to share the crash report but there are some sensitive information inside that dump.
So would like to understand who will have access to the information which are shared via the report function.

In any case I would like to understand why the crash / reboot happened.

Code Select Expand

db:0:kdb.enter.default>  bt
Tracing pid 0 tid 100229 td 0xfffff800020e8740
kdb_enter() at kdb_enter+0x33/frame 0xfffffe0035f40e00
panic() at panic+0x43/frame 0xfffffe0035f40e60
dblfault_handler() at dblfault_handler+0x1ce/frame 0xfffffe0035f40f20
Xdblfault() at Xdblfault+0xd7/frame 0xfffffe0035f40f20
--- trap 0x17, rip = 0xffffffff80fbaaa9, rsp = 0xfffffe0106df0fd0, rbp = 0xfffffe0106df10a0 ---
AES_GCM_decrypt() at AES_GCM_decrypt+0x1959/frame 0xfffffe0106df10a0
aesni_cipher_crypt() at aesni_cipher_crypt+0x30f/frame 0xfffffe0106df1170
aesni_process() at aesni_process+0xc6/frame 0xfffffe0106df11a0
crypto_dispatch_one() at crypto_dispatch_one+0xde/frame 0xfffffe0106df11c0
ovpn_udp_input() at ovpn_udp_input+0x492/frame 0xfffffe0106df1270
udp_append() at udp_append+0x67/frame 0xfffffe0106df12f0
udp_input() at udp_input+0x8bb/frame 0xfffffe0106df13e0
ip_input() at ip_input+0x26f/frame 0xfffffe0106df1440
netisr_dispatch_src() at netisr_dispatch_src+0x9f/frame 0xfffffe0106df1490
ovpn_finish_rx() at ovpn_finish_rx+0x405/frame 0xfffffe0106df14e0
ovpn_decrypt_rx_cb() at ovpn_decrypt_rx_cb+0x1a1/frame 0xfffffe0106df1590
aesni_process() at aesni_process+0xea/frame 0xfffffe0106df15c0
crypto_dispatch_one() at crypto_dispatch_one+0xde/frame 0xfffffe0106df15e0
ovpn_udp_input() at ovpn_udp_input+0x492/frame 0xfffffe0106df1690
From the backtrace it looks like that something in OpenVPN got messed up.
Could it be that the OpenVPN daemon did not get restarted after the update?
I'm using DCO so maybe the kernel driver and the binary did not match.
It is just an idea.

Best regards
Timmi

Installation of the three patches fixed it for us as well.

I have open a feature request on Github
https://github.com/opnsense/plugins/issues/3905

Hi all,

just starting to enjoy the nginx plugin.
Currently performing some tests with one sample web app.
I also configured a remote syslog target but I'm only receiving the access log.
What about the error log?

Is this a bug or do I miss some configuration?

Best regards
Timmi

Since 6d it did not crash.

[Service Test Settings:]

Sure, I assume Monit is running already.

Service Test Settings:
Name: Crowdsec_Service
Condition: failed host 127.0.0.1 port 8080 type tcp
Action: Restart

Service Settings:
Enable service checks: yes
Name: Crowdsec
Type: Process
PID File: /var/run/crowdsec.pud
Start: /usr/sbin/service crowdsec start
Stop: /usr/sbin/service crowdsec stop
Tests: Crowdsec_Service
Depends: Nothing selected
Description: Check that Crowdsec is running

I have created a Monit test to restart the service is it is not running.

So the service should be back within two minutes.

Not for me as WAL mode is enabled.
I also don't receive the warning.

I know.
As I wrote I don't see anything specific in the crowdsec.log at that time. Just no logs anymore at some point.
Only the bouncer log is showing that the LAPI is not available as I wrote.

like this

time="08-03-2024 12:45:32" level=info msg="1 decision added"


This is what is shown if the system is running.

Hi,

I see in /var/log/crowdsec/crowdsec-firewall-bouncer.log

time="08-03-2024 01:00:52" level=error msg="auth-api: auth with api key failed return nil response, error: dial tcp 172.28.52.65:8080: i/o timeout"
time="08-03-2024 01:00:52" level=error msg="Get \"http://192.168.1.1:8080/v1/decisions/stream?\": dial tcp 192.168.1.1:8080: i/o timeout"

Hi All,

since a few weeks I noticed that the Crowdsec daemon is stopping / crashing at 1am (which should be UTC midnight).
I don't see anything in the crowdsec logs.

I'm not sure if this is happening since OPNsense 24 or if my IPv6 changes added additional load on the server. I would say the LAPI server is gone as I can see that the bounce is still trying to communicate.

Could it be that the local LAPI server is at the capacity limit?
Service is looking normal after starting it again.

Thank for your help
Timmi