• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
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.
  • N
    noplan @Bob.Dig
    last edited by Dec 23, 2020, 2:00 PM

    @bob-dig

    old client with new exported config was here the reproduced problem
    new client with same config worked

    if this happens when u update to 2.4.5-RELEASE-p1 there will be troubles ...

    1 Reply Last reply Reply Quote 0
    • B
      Bob.Dig LAYER 8
      last edited by Dec 29, 2020, 6:52 PM

      Still only working from LAN, not from internet. Anyone else got some ideas?

      1 Reply Last reply Reply Quote 0
      • I
        impact1560
        last edited by Jan 1, 2021, 2:00 AM

        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
        • B
          Bob.Dig LAYER 8
          last edited by Bob.Dig Jan 11, 2021, 2:35 PM Jan 11, 2021, 1:06 PM

          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
          • B
            Bob.Dig LAYER 8
            last edited by Bob.Dig Jan 11, 2021, 1:43 PM Jan 11, 2021, 1:33 PM

            This post is deleted!
            V 1 Reply Last reply Jan 11, 2021, 1:35 PM Reply Quote 0
            • V
              viragomann @Bob.Dig
              last edited by Jan 11, 2021, 1:35 PM

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

              B 1 Reply Last reply Jan 11, 2021, 1:57 PM Reply Quote 0
              • B
                Bob.Dig LAYER 8 @viragomann
                last edited by Bob.Dig Jan 11, 2021, 2:36 PM Jan 11, 2021, 1:57 PM

                @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 Jan 11, 2021, 3:14 PM Reply Quote 0
                • V
                  viragomann @Bob.Dig
                  last edited by Jan 11, 2021, 3:14 PM

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

                  B 1 Reply Last reply Jan 11, 2021, 3:24 PM Reply Quote 0
                  • B
                    Bob.Dig LAYER 8 @viragomann
                    last edited by Jan 11, 2021, 3:24 PM

                    @viragomann According to the firewall log they are.

                    Capture.PNG

                    1 Reply Last reply Reply Quote 0
                    • B
                      Bob.Dig LAYER 8
                      last edited by Jan 11, 2021, 5:16 PM

                      Maybe @JeGr has an idea?

                      J 1 Reply Last reply Jan 12, 2021, 12:04 AM Reply Quote 0
                      • J
                        JeGr LAYER 8 Moderator @Bob.Dig
                        last edited by Jan 12, 2021, 12:04 AM

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

                        B 1 Reply Last reply Jan 12, 2021, 8:21 AM Reply Quote 1
                        • B
                          Bob.Dig LAYER 8 @JeGr
                          last edited by Bob.Dig Jan 12, 2021, 8:25 AM Jan 12, 2021, 8:21 AM

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

                          J 1 Reply Last reply Jan 13, 2021, 1:29 AM Reply Quote 0
                          • J
                            JeGr LAYER 8 Moderator @Bob.Dig
                            last edited by Jan 13, 2021, 1:29 AM

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

                            B 1 Reply Last reply Jan 13, 2021, 9:45 AM Reply Quote 1
                            • B
                              Bob.Dig LAYER 8 @JeGr
                              last edited by Bob.Dig Jan 13, 2021, 11:31 AM Jan 13, 2021, 9:45 AM

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

                              J 1 Reply Last reply Jan 20, 2021, 12:43 AM Reply Quote 0
                              • J
                                JeGr LAYER 8 Moderator @Bob.Dig
                                last edited by JeGr Jan 20, 2021, 12:44 AM Jan 20, 2021, 12:43 AM

                                @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.
                                  This community forum collects and processes your personal information.
                                  consent.not_received