OpenVPN assert in ssl.c (line 1857) on Feb 8 snap (was fine on Feb 4 snap)
-
I have tried rebooting a few times and re-applying the openvpn config (disabling/re-enabling in web configurator) and sometimes it won't assert but instead give me these errors:
openvpn[37554]: 216.75.224.218:7393 TLS_ERROR: BIO read tls_read_plaintext error: error:1408F06B:SSL routines:SSL3_GET_RECORD:bad decompression
openvpn[37554]: 216.75.224.218:7393 TLS Error: TLS object -> incoming plaintext read error
openvpn[37554]: 216.75.224.218:7393 TLS Error: TLS handshake failedI have tried disabling AES-NI as well with no changes in the results.
/wj
-
Manually replacing /usr/local/lib/libssl.so* with the version from the Feb 04 snapshot will let the OpenVPN server run again. Not an ideal solution, but shows that the openssl upgrade seems to cause the issue.
/wj
-
Yeah seems an openssl issue that will resolve as soon as upstream resolves the issue.
The urgent upgrade was done due to security issues released lately. -
Understood. Will keep an eye out for changes in either OpenVPN or OpenSSL. Not sure if the updated OpenSSL triggered a bug somewhere in OpenVPN or if this is an actual issue within OpenSSL itself. Doesn't seem to be a very common problem though, as I couldn't locate any other bug reports that looked similar to this case…
UPDATE: Well, after some more Googling posts like this turned up: http://lists.freebsd.org/pipermail/freebsd-ports/2013-February/081259.html
(basically explaining that OpenSSL 1.0.1d is broken) - so let's see how 1.0.1e performs when that is available from upstream./wj
-
Thanks merging the fix in our port until final 1.0.1e comes out.
-
I have now successfully gotten OpenVPN to work again with the 20130209-1139 snapshot, so the fix seems to be just what was needed, thanks for the quick fix!!
Don't be fooled by the reported 1.0.1.d Feb 5 2013 label from /usr/loca/bin/openssl version, this snapshot definitely comes with a patched version.
/wj
-
Had this same problem and the update today fixed the issues for me as well.
However, for some reason I had no default route when pfsense booted. I had to add it manually from the shell. I checked my config and it seems correct…I'm not sure what happened. I'll have to test more later...
-
I can confirm the lack of default route after an upgrade to today's snapshot. I too was having the ssl issue, so went for an update.
I think I'll make this a separate post, as something must be broken if I'm not the only one with the default gateway issue after today's snapshot.
-
However, for some reason I had no default route when pfsense booted.
I can confirm the lack of default route after an upgrade to today's snapshot.
That's odd, it's been a long time since I saw routes not being applied during boot, but in my case the default route is provisioned using DHCP. Are yours a static default route by any chance?
/wj
-
(I'll switch this over to the new thread I just started)