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

openVPN issue after yesterday update

Scheduled Pinned Locked Moved 2.5 Development Snapshots (Retired)
15 Posts 6 Posters 14.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.
  • B
    Beerman
    last edited by Dec 22, 2020, 9:12 PM

    Today I tried the newest Build:

    2.5.0-DEVELOPMENT (amd64)
    built on Tue Dec 22 03:01:05 EST 2020

    Unfortunately, the same problem. And there are only the 5 openvpn log events I mentioned in the first post.

    Works fine in the 2.4.5-p1 version, and did worked fine in the 2.5.0 version before the 17th of December.

    1 Reply Last reply Reply Quote 0
    • J
      jimp Rebel Alliance Developer Netgate
      last edited by Dec 31, 2020, 8:19 PM

      There is nothing wrong with OpenVPN on snapshots here.

      Maybe your certificates are actually not valid? Maybe expired?

      Remember: Upvote with the ๐Ÿ‘ button for any user/post you find to be helpful, informative, or deserving of recognition!

      Need help fast? Netgate Global Support!

      Do not Chat/PM for help!

      B 1 Reply Last reply Dec 31, 2020, 10:56 PM Reply Quote 0
      • B
        Beerman @jimp
        last edited by Dec 31, 2020, 10:56 PM

        @jimp Thx, for reply! :)

        I have just tested the current snapshot, unfortunately without success.

        At the moment, I cannot see any issues with my certificates. No expired cert.
        Is the the possibility to turn on debug logs for openVPN?

        It's funny that it already worked with the verfsion 2.5 , only unfortunately since the 17th of December it doesnยดt anymore.

        Q 1 Reply Last reply Mar 9, 2021, 11:53 AM Reply Quote 0
        • B
          Beerman
          last edited by Beerman Jan 2, 2021, 5:40 PM Jan 2, 2021, 5:37 PM

          Today I have tested a little bit again.

          So I updated my system to version "2.5.0-DEVELOPMENT (amd64)
          built on Sat Jan 02 03:00:38 EST 2021" from version "2.4.5-RELEASE-p1".

          I also came across the following thread:
          https://forum.netgate.com/topic/98244/pfsense-2-3-tls-handshake-failed-failed-running-command-tls-verify-script/7

          There I found the post of "v0lZy" from Dec 28, 2017, 1:25 PM who had a similar problem.
          https://forum.netgate.com/post/743055

          I then changed "Certificate Depth" to "Do not Check" and then the connection worked again. Before that, the setting was on "One (Client+Server)".

          When I change the setting back to "One (Client+Server)", I get the same error messages again:

          WARNING: Failed running command (--tls-verify script): external program exited with error status: 1
          OpenSSL: error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed
          TLS_ERROR: BIO read tls_read_plaintext error
          TLS Error: TLS object -> incoming plaintext read error
          TLS Error: TLS handshake failed
          

          (Unfortunately wirh no more information)

          CA, Server Cert and User Cert were generated on the same system.

          1 Reply Last reply Reply Quote 2
          • J
            jimp Rebel Alliance Developer Netgate
            last edited by Jan 4, 2021, 1:15 PM

            How long is the subject on that certificate?

            The only similar failure I can recall like that which could be related is https://redmine.pfsense.org/issues/4521 but that has been broken a long time and wouldn't have only broken recently.

            Remember: Upvote with the ๐Ÿ‘ button for any user/post you find to be helpful, informative, or deserving of recognition!

            Need help fast? Netgate Global Support!

            Do not Chat/PM for help!

            B 1 Reply Last reply Jan 4, 2021, 3:14 PM Reply Quote 0
            • B
              Beerman @jimp
              last edited by Jan 4, 2021, 3:14 PM

              @jimp

              Server Cert:
              C=XX,ST=Xxxxxxx,L=Xxxxxx,O=Xxxxxx,emailAddress=xxxxxxx@xxxxxx.xxxxx,CN=xxx-xxxxx.xxxxxx.xxxxx,OU=xxxxxxx.xxxxxx.xxxxx

              Length: 118

              Client Cert:
              CN=xxx_xxxxxxx_xxx,C=XX,ST=Xxxxxxx,L=Xxxxxx,O=Xxxxxx,OU=xxxxxxx.xxxxxx.xxxxx

              Length: 77

              Seems not the problem...

              B 1 Reply Last reply Jan 10, 2021, 5:11 PM Reply Quote 0
              • B
                Beerman @Beerman
                last edited by Jan 10, 2021, 5:11 PM

                In the meantime, I created a new CA and new certificates, and with these it did work again.

                And finally my blind eyes also found the option "Verbosity level" ๐Ÿ˜ So i did test the connection again, with the original CA/certificates.

                Here is the interesting part of the logs:

                TLS Error: TLS handshake failed
                TLS Error: TLS object -> incoming plaintext read error
                TLS_ERROR: BIO read tls_read_plaintext error
                OpenSSL: error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed
                SSL alert (write): fatal: internal error
                VERIFY SCRIPT ERROR: depth=1, C=XX, ST=Xxxxxxx, L=Xxxxxx, O=Yyyyy, emailAddress=openvpn@xxxxxx.yyyyy, CN=internal-ca.openvpn.xxxxxx.yyyyy, OU=openvpn.xxxxxx.yyyyy
                WARNING: Failed running command (--tls-verify script): external program exited with error status: 1
                TLS: executing verify command: /usr/local/sbin/ovpn_auth_verify tls srv-yyy99.xxxxxx.yyyyy 1 1 C=XX, ST=Xxxxxxx, L=Xxxxxx, O=Yyyyy, emailAddress=openvpn@xxxxxx.yyyyy, CN=internal-ca.openvpn.xxxxxx.yyyyy, OU=openvpn.xxxxxx.yyyyy
                SSL state (accept): TLSv1.3 early data
                Incoming Ciphertext -> TLS
                BIO write tls_write_ciphertext 1250 bytes
                ACK reliable_can_send active=0 current=0 : [8]
                TLS: tls_process: chg=0 ks=S_START lame=S_UNDEF to_link->len=0 wakeup=604800
                TLS: tls_multi_process: i=0 state=S_START, mysid=dc99e6a0 aa7269fa, stored-sid=36c952ab c7d44a4d, stored-ip=[AF_INET]80.xxx.yyy.zzz:28500
                
                D 1 Reply Last reply Feb 19, 2021, 2:12 PM Reply Quote 1
                • D
                  darcey @Beerman
                  last edited by darcey Feb 19, 2021, 2:19 PM Feb 19, 2021, 2:12 PM

                  @beerman
                  I have certificate depth 1, a custom root CA and no intermediate CA.
                  I just upgraded 2.4.5-p3 (with a long-term working openvpn config) to 2.5.0. Now CA verification fails.
                  The log says /usr/local/sbin/ovpn_auth_verify returns 1. However, running the stated command from the terminal returns zero. Turning off CA verification allows client to connect successfully.
                  I wonder why openvpn process apparently sees a return value of 1 whilst I see zero from a root shell. I'd rather not regenerate certificates, though I did try just resaving them from web UI with no joy. So I have turned off tls depth verification for the time being.

                  R 1 Reply Last reply Feb 24, 2021, 11:47 AM Reply Quote 1
                  • R
                    reshadp @darcey
                    last edited by Feb 24, 2021, 11:47 AM

                    @darcey
                    I have the same issue.
                    Disabling certificate depth works, but I rather have a strict check.
                    OpenVPN adds additional environment variables and parameters at the end of the command so we need to test with those.

                    Also the shell script which does the TLS check has changed since the previous release (2.4.5-p1)

                    D 1 Reply Last reply Feb 24, 2021, 12:01 PM Reply Quote 1
                    • D
                      darcey @reshadp
                      last edited by Feb 24, 2021, 12:01 PM

                      @reshadp
                      I am not so sure my statement re running the certificate check successfully via the command line was correct! I may have passed certifcate serial & config incorrectly to the script.
                      I have since removed the old CA and associated certificates, and generated a new PKI, this time via the pfsense web UI. The certificate depth check is now successful. So have re-enabled the check in the openvpn server config.
                      I'm not sure what changes between 2.4.5-p3 and 2.5.0 render a depth check of my previous PKI invalid.

                      1 Reply Last reply Reply Quote 0
                      • D
                        DeaDSouL
                        last edited by Feb 24, 2021, 3:13 PM

                        I have the same issue since I've upgraded my pfSense to 2.5.0

                        1 Reply Last reply Reply Quote 0
                        • D
                          darcey
                          last edited by Feb 24, 2021, 3:58 PM

                          I've not looked at the changes WRT to certificate depth check, but one way my previous certs (CA included) differ from those generated using the web UI, is an email field amongst the distinguished name fields. Apparently spaces should not cause any issues, but I've also avoided using them in the newly created PKI.

                          1 Reply Last reply Reply Quote 0
                          • D
                            DeaDSouL
                            last edited by DeaDSouL Feb 24, 2021, 7:15 PM Feb 24, 2021, 7:13 PM

                            Here is the fix for the issue. (It worked for me)

                            1 Reply Last reply Reply Quote 0
                            • Q
                              qctech @Beerman
                              last edited by Mar 9, 2021, 11:53 AM

                              Props to @Beerman

                              I was having the same issue at a site where fortunately the VPN is not mission critical. Your post pointed me in the right direction and it's now resolved.

                              New CA, server cert, user cert applied to the existing OpenVPN setup, new client config exported and it all works like it should.

                              1 Reply Last reply Reply Quote 0
                              • First post
                                Last post
                              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                                This community forum collects and processes your personal information.
                                consent.not_received