Netgate Discussion Forum
    • Categorias
    • Recente
    • Tags
    • Popular
    • Usuários
    • Pesquisar
    • Cadastrar
    • Login

    OpenVPN Errors - TLS handshake failed

    Agendado Fixado Trancado Movido Firewalling
    9 Posts 5 Posters 67.2k Visualizações
    Carregando Mais Posts
    • Mais Antigo para Mais Recente
    • Mais Recente para Mais Antigo
    • Mais Votados
    Responder
    • Responder como tópico
    Entre para responder
    Este tópico foi deletado. Apenas usuários com privilégios de moderação de tópico podem vê-lo.
    • A Offline
      alltime
      última edição por

      OpenVPN is configured thanks to the following YouTube video: https://www.youtube.com/watch?v=VdAHVSTl1ys

      However, we are unable to connect and receive the error following error:

      Wed Sep 03 14:44:23 2014 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
      Wed Sep 03 14:44:23 2014 TLS Error: TLS handshake failed
      Wed Sep 03 14:44:23 2014 SIGUSR1[soft,tls-error] received, process restarting

      Are there firewall rules that must be created in order to establish a connection? Last year, we followed that video an were successful without connections, without doing anything special. Our users are authenticating using RADIUS (which works since have captive portal working also), and we are using port 1194.

      1 Resposta Última resposta Responder Citar 0
      • K Offline
        kejianshi
        última edição por

        Well - Yes - You have to open the port that the vpn server communicates on.  Thats a simple firewall rule on the WAN to pass traffic, either udp or tcp depending on what you are using.  Not a NAT rule.

        If you used the wizard, a port should have been opened on the WAN for you.

        Got to firewall, rules, WAN and check to see if its there.

        Also, clock sync can be an issue if the client is ahead of time/date compared to the server.

        Good to provide a good NTP server list.

        1 Resposta Última resposta Responder Citar 0
        • KOMK Offline
          KOM
          última edição por

          Also, ensure that:

          1. The OpenVPN client setup must be installed by Administator

          2. The OpenVPN client must be run as Administator

          In other words, everything about OpenVPN client requires UAC elevation.

          1 Resposta Última resposta Responder Citar 0
          • A Offline
            alltime
            última edição por

            @kejianshi:

            Well - Yes - You have to open the port that the vpn server communicates on.  Thats a simple firewall rule on the WAN to pass traffic, either udp or tcp depending on what you are using.  Not a NAT rule.

            If you used the wizard, a port should have been opened on the WAN for you.

            Got to firewall, rules, WAN and check to see if its there.

            Also, clock sync can be an issue if the client is ahead of time/date compared to the server.

            Good to provide a good NTP server list.

            The rule was definitely created. I went ahead and moved the rule to the top of the list, but same results. Through the Wizard, we chose to use UDP.

            @KOM:

            Also, ensure that:

            1. The OpenVPN client setup must be installed by Administator

            2. The OpenVPN client must be run as Administator

            In other words, everything about OpenVPN client requires UAC elevation.

            I went ahead and uninstalled the client, reinstalled with the same result.

            1 Resposta Última resposta Responder Citar 0
            • ? This user is from outside of this forum
              Visitante
              última edição por

              Tried an alternative port in the 30-40-50-60-thousand-something range?

              Just give it a try, don't forget to adjust the firewall rule for the server….

              1 Resposta Última resposta Responder Citar 0
              • ? This user is from outside of this forum
                Visitante
                última edição por

                EDIT: Why did you delete your reply to my first post?  :o

                Anyways:

                https://forums.openvpn.net/topic12938.html

                http://serverfault.com/questions/92312/openvpn-tls-error-tls-key-negotiation-failed-to-occur-within-60-seconds

                • misconfig of server/client

                • something wrong with certificates

                • firewall blocking somewhere inbetween

                …as the bottom line... ;)

                1 Resposta Última resposta Responder Citar 0
                • A Offline
                  alltime
                  última edição por

                  It looked like a pointless post. I wanted to troubleshoot a little more!  :D

                  1 Resposta Última resposta Responder Citar 0
                  • K Offline
                    kejianshi
                    última edição por

                    Is lime a "WAN" port?

                    You know - Multi "Wan"…    You could also be having a gateway problem or outbound NAT problem.

                    1 Resposta Última resposta Responder Citar 0
                    • A Offline
                      adbrown1982
                      última edição por

                      I know this topic is long closed.

                      However for any future reader with this issue using the OpenVPN client exported from PFsense there are a few things to check which may help you.

                      If you are using a Radius server, perhaps the Microsoft Network Policy Server. And youve checked all the obvious usch as ports on PFsense, firewall entries, shared key etc etc

                      The first port of call is via PFSENSE –> diagnostics --> authentication

                      If you use a radius server this will be in the drop down list, pick this and enter a username and password thats authenticating with this radius server. your active directory username and password, or the user in question.

                      If this fails then youve narrowed the issue down to the radius server itself.

                      Go to services and ensure the network policy server service is running.

                      For me following an in place upgrade of the server OS this service was no longer set to automatic and after many hours of focusing on the client side, uninstalling, re-adding. searching the net for answers i eventually got to the bottom of it.

                      So for anyone else in my position i hope this helps and saves you a lot of time.

                      CHECK THE RADIUS SERVER SERVICE IS RUNNING! :)

                      1 Resposta Última resposta Responder Citar 0
                      • Primeiro post
                        Último post
                      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.