Messages

Saw a similar issue today where WAN become unresponsive after upgrading from 25.1.12 to 25.7.2 last week. Unfortunately it was at a remote site, so I had limited diagnostic options. About an hour before WAN became unresponsive I saw latency for all traffic through going through the WAN interface skyrocket (500-1500 ms extra latency compared to regular). After that WAN connectivity dropped completely, but LAN traffic between multiple VLANs kept working. A reboot fixed the issue, but we'll see it becomes a reoccurring problem.

'RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller' NIC. Intel Celeron N3150 CPU. os-realtek-re plugin is installed. Although Realtek isn't ideal the machine has been stable for several years with earlier versions of OPNsense.


After the incident I digged through the logs, but didn't find anything too interesting (that I could make sense of). Although this notice that was repeated at least three times (in Log Files: General) did look a bit suspicious:

Code Select Expand

<7>[557293] sonewconn: pcb 0xfffff800438fc000 (0.0.0.0:53 (proto 6)): Listen queue overflow: 49 already in queue awaiting acceptance (208 occurrences), euid 0, rgid 0, jail 0
Right now I configured the "hw.pci.enable_aspm = 0" tuneable just in case.

3. The "Compression" dropdown box is gone, and this is where I got stuck - I need to set it to "Partial" (e.g. --compress) for the connection to my VPN provider to work

The general recommendation is to move away from using compression because it introduces unnecessary vulnerabilities. However, if you need to support OpenVPN clients that are requesting compression, then you can configure the OpenVPN server option "compress migrate". This option is also exposed in the new OPNsense OpenVPN instance configuration page if you select "advanced mode".

## Ha, on second read I realised you're looking to configure the OpenVPN client, not the server. Feel free to ignore this. : o)

When configuring an OpenVPN server where the "Certificate Revocation List" is in OPNsense's Trust store and where "Verify Client Certificate" is set to "required", the OpenVPN server logs the following warnings:

Code Select Expand

2025-07-07T20:10:22 Warning openvpn_server1  {IP_REDACTED}:57866 CRL: cannot read CRL from file /var/etc/openvpn/server-2eb6ff80-fa3f-4c59-a785-acca7c44f471.crl-verify
2025-07-07T20:10:22 Warning openvpn_server1  {IP_REDACTED}:57866 OpenSSL: error:0480006C:PEM routines::no start line:
2025-07-07T20:10:22 Warning openvpn_server1  {IP_REDACTED}:57866 OpenSSL: error:0308010C:digital envelope routines::unsupported:Global default library context, Algorithm (none : 0), Properties (<null>)
My first thought was that perhaps the CRL is malformed, but when verifying the contents of the CRL file with openssl, the CRL seems to be valid:

Code Select Expand

root@mono:~ # openssl crl -in /var/etc/openvpn/server-2eb6ff80-fa3f-4c59-a785-acca7c44f471.crl-verify -inform PEM -CAfile ca.crt -noout
verify OK
There also shouldn't be a problem with file permissions – the CRL file has 644 permissions and its parent directories are world accessible. Besides, the OpenVPN server process runs as root.

The structure of the CRL file is:

Code Select Expand

-----BEGIN X509 CRL-----
BASE64 CRL
-----END X509 CRL-----
When revoking certificates, it appears that the OpenVPN server can actually read the CRL, as the revoked certs can no longer be used to connect to the OpenVPN server. However, seeing those warnings still makes me feel uneasy. Any thoughts on what's causing these warnings? Am I in for further problems down the line?

All of this is happening on OPNsense 25.1.10-amd64.