Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    OpenVPN assert in ssl.c (line 1857) on Feb 8 snap (was fine on Feb 4 snap)

    Scheduled Pinned Locked Moved 2.1 Snapshot Feedback and Problems - RETIRED
    11 Posts 4 Posters 3.5k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • W
      wernerj
      last edited by

      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 failed

      I have tried disabling AES-NI as well with no changes in the results.

      /wj

      1 Reply Last reply Reply Quote 0
      • W
        wernerj
        last edited by

        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

        1 Reply Last reply Reply Quote 0
        • E
          eri--
          last edited by

          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.

          1 Reply Last reply Reply Quote 0
          • W
            wernerj
            last edited by

            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

            1 Reply Last reply Reply Quote 0
            • E
              eri--
              last edited by

              Thanks merging the fix in our port until final 1.0.1e comes out.

              1 Reply Last reply Reply Quote 0
              • W
                wernerj
                last edited by

                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

                1 Reply Last reply Reply Quote 0
                • L
                  lucky
                  last edited by

                  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...

                  1 Reply Last reply Reply Quote 0
                  • C
                    cforger
                    last edited by

                    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.

                    1 Reply Last reply Reply Quote 0
                    • W
                      wernerj
                      last edited by

                      @lucky:

                      However, for some reason I had no default route when pfsense booted.

                      @cforger:

                      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

                      1 Reply Last reply Reply Quote 0
                      • C
                        cforger
                        last edited by

                        (I'll switch this over to the new thread I just started)

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.