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

    [solved] TLS Error: TLS handshake failed

    Scheduled Pinned Locked Moved OpenVPN
    18 Posts 5 Posters 4.0k 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.
    • I
      impact1560
      last edited by

      I'm also having these same issues. I tried to reinstall but I keep getting the same error message.

      1 Reply Last reply Reply Quote 0
      • Bob.DigB
        Bob.Dig LAYER 8
        last edited by Bob.Dig

        I made a complete new server with the wizard on 2.4.5-RELEASE-p1. But still the same problem with OpenVPN for Android, from inside it works, from external it is not. I also disabled the OVPN 2.5 settings this time, doesn't help.

        Capture.PNG

        Any help appreciated.

        persist-tun
        persist-key
        cipher AES-256-GCM
        auth SHA512
        tls-client
        client
        remote 192.168.201.1 41174 udp
        remote xxx.xx 41174 udp
        verify-x509-name "NewClient" name
        auth-user-pass
        remote-cert-tls server
        
        1 Reply Last reply Reply Quote 0
        • Bob.DigB
          Bob.Dig LAYER 8
          last edited by Bob.Dig

          This post is deleted!
          V 1 Reply Last reply Reply Quote 0
          • V
            viragomann @Bob.Dig
            last edited by

            @bob-dig
            Possibly there are more details in the client log.

            Bob.DigB 1 Reply Last reply Reply Quote 0
            • Bob.DigB
              Bob.Dig LAYER 8 @viragomann
              last edited by Bob.Dig

              @viragomann said in TLS Error: TLS handshake failed:

              @bob-dig
              Possibly there are more details in the client log.

              There are not, it is the same message like shown in the first post.

              1194 is the source port, don't know why it is the default, but anyway, it is not the source of the problem at least.
              Still not working here.

              V 1 Reply Last reply Reply Quote 0
              • V
                viragomann @Bob.Dig
                last edited by

                @bob-dig said in TLS Error: TLS handshake failed:

                There are not, it is the same message like shown in the first post.

                That is the common log if the client is not able to reach the server.
                So check if the packets are arriving properly on WAN at 41174 UDP.

                @bob-dig said in TLS Error: TLS handshake failed:

                1194 is the source port, don't know why it is the default, but anyway, it is not the source of the problem at least.

                As long as the client only establishes a single connection.
                For multiple add

                lport 0
                

                to the clients config file.

                Bob.DigB 1 Reply Last reply Reply Quote 0
                • Bob.DigB
                  Bob.Dig LAYER 8 @viragomann
                  last edited by

                  @viragomann According to the firewall log they are.

                  Capture.PNG

                  1 Reply Last reply Reply Quote 0
                  • Bob.DigB
                    Bob.Dig LAYER 8
                    last edited by

                    Maybe @JeGr has an idea?

                    JeGrJ 1 Reply Last reply Reply Quote 0
                    • JeGrJ
                      JeGr LAYER 8 Moderator @Bob.Dig
                      last edited by

                      @bob-dig So works from inside but not from outside? How's it configured on the WAN side then?

                      Don't forget to upvote ๐Ÿ‘ those who kindly offered their time and brainpower to help you!

                      If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

                      Bob.DigB 1 Reply Last reply Reply Quote 1
                      • Bob.DigB
                        Bob.Dig LAYER 8 @JeGr
                        last edited by Bob.Dig

                        @jegr Hey, maybe you can help.
                        It is just an open port to the pfSense WAN-Interface. And the result can be seen in the picture above. fritzbox in between and pfSense is the exposed host.
                        In the openvpn client config I have two addresses, DDNS of my WAN and the pfSense Interface on my Wifi.
                        In the server wizard I had selected this WAN-Interface and UDP 4&6 on all interfaces (Multihome).

                        JeGrJ 1 Reply Last reply Reply Quote 0
                        • JeGrJ
                          JeGr LAYER 8 Moderator @Bob.Dig
                          last edited by

                          @bob-dig Huh and it works on Wifi but not on WAN? Or vice versa? Would have to rebuild that scenario myself, can't see why it shouldn't be working. I would've used two port forwards instead and bound the server to localhost/udp1194 to simplify as I've seen strange things with that multihome config.

                          Don't forget to upvote ๐Ÿ‘ those who kindly offered their time and brainpower to help you!

                          If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

                          Bob.DigB 1 Reply Last reply Reply Quote 1
                          • Bob.DigB
                            Bob.Dig LAYER 8 @JeGr
                            last edited by Bob.Dig

                            @jegr So I setup one server without the wizard listening on any and it worked, although I had to reboot pfSense to get "the surfing" working too.
                            And you can port forward towards localhost? Have never done this.
                            But maybe it would be easier to host the OVPN Server on the "Wifi" Interface and do a portforward from WAN to it. Thanks Jens!

                            So problem is solved by not using "multihome" in the first place.

                            JeGrJ 1 Reply Last reply Reply Quote 0
                            • JeGrJ
                              JeGr LAYER 8 Moderator @Bob.Dig
                              last edited by JeGr

                              @bob-dig And you can port forward towards localhost? Have never done this.

                              Sure why wouldn't it? Localhost is a normal interface. 127.x.x.x are "normal" IP addresses. No reason why a service or daemon shouldn't run or listen on localhost or a localhost-style IP address. Many developers e.g. in Ops or DevOps use local development tools and servers to test on their own machines (because faster) and bind e.g. a web-stack for rapid development to localhost. OpenVPN isn't really anything special in that consideration.

                              Also it's really one of the defaults to run an OpenVPN server on localhost when dealing with MultiWAN. You don't want two different servers for every WAN but same IP space, same settings, same certs etc. so easiest way is to "bind" it to localhost so it is awaiting traffic and just use two port forwards on the appropriate interfaces to direct traffic to it from those WANs. The same could be done with your internal WiFi network, too. Plus side is, that port forwards also use "reply-to" parameters of pf so traffic should always return the way same way out it "got into" the OVPN server in the first place.
                              We've customers running 4 DSL and 1 fibre line and for easier migration we configured their OVPN server to listen on localhost and redirect traffic from all those WANs to it. So if anyone is still using an old DSL IP it's still working :)

                              Multihome should make that configuration easier and also add multi-link support for IPv4+IPv6 but somehow multihome still makes trouble when running. Either in selecting the wrong IP family or in some other fashion like your problem that doesn't really make much sense...

                              Don't forget to upvote ๐Ÿ‘ those who kindly offered their time and brainpower to help you!

                              If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

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