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

    Unable to connect to vpn server if vpn client is runing

    OpenVPN
    3
    7
    1.1k
    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.
    • M
      mdahal
      last edited by

      Good evening,

      I have successfully set up one vpn server to use as road wariror and 2 clients for selective routing using PIA.

      However, every time I try to connect to the server when clients are running the connection is stuck at waiting for server and get  TLS key negotiation failed to occur within 60 seconds (check your network connectivity) in pfsense openvpn log.

      If I stop both clients I am able to connect again to server. My clients are connected fine and can route to it.
      LAN - 192.168.2.0/24
      OpenVPN Server : 10.0.0.0/24
      Clinet 1 connected: 10.16..
      Client 2 connected: 10.20..

      I have checked everywhere but unable to fix the issue.

      The only area I am not certain is outbound NAT. do I have to add any rule to allow VPN Connection.

      Appreciate your help.

      ![Screen Shot 2018-01-15 at 12.40.19 am.png](/public/imported_attachments/1/Screen Shot 2018-01-15 at 12.40.19 am.png)
      ![Screen Shot 2018-01-15 at 12.40.19 am.png_thumb](/public/imported_attachments/1/Screen Shot 2018-01-15 at 12.40.19 am.png_thumb)

      1 Reply Last reply Reply Quote 0
      • V
        viragomann
        last edited by

        Presumably you get the default route pushed by the PIA server. So responses to VPN connection requests are sent out to the PIA gateway.

        You have to assign an interface to each VPN instance. Based on your outbound NAT rule, I guess you haven't done this yet.

        To avoid that, go to the client setting and check "Don't pull routes".
        Since you want set up selective routing to the PIA gateway, you have to set policy routing rules for directing traffic to PIA using the gateway you've assigned to the vpn instances.

        Your outbound NAT rules are very strange. What is 10.10.10.1?
        Have you defined a gateway on the WIFI interface? If yes, why?
        What is IPMI? Have you defined a gateway on this interface? Why?

        OpenVPN is an interface group containing all OpenVPN instances. You should define rules for each particular PIA VPN interface.

        1 Reply Last reply Reply Quote 0
        • M
          mdahal
          last edited by

          Thank you Viragomann,

          Really appreciate your help.

          I have added  route for one which made both work. Its the vpn to one. I have also created interface for each vpn instance.

          I will try using "Don't pull routes" and report tonight.

          Furthermore,
          10.10.10.1 was another vpn server I had which is deleted now.
          IPMI and WIFI are two interfaces that are't connected at ghe moment but I am planning to run wifi and all my devices management through them.

          Cheers

          1 Reply Last reply Reply Quote 0
          • DerelictD
            Derelict LAYER 8 Netgate
            last edited by

            Presumably you get the default route pushed by the PIA server. So responses to VPN connection requests are sent out to the PIA gateway.

            That is not actually true. Unless the functionality has been disabled (or something silly like using an interface group for WAN rules), connections coming into a WAN interface get marked with reply-to forcing reply traffic back out the same interface on which it arrived regardless of the contents of the routing table.

            I have not quite wrapped my head around why multiple OpenVPN connections give people so much trouble.

            Outbound NAT means nothing when connecting TO an OpenVPN server. Bad OB NAT might prevent you from being able to access the internet through that server after you have connected, but it will not impact the connection at all.

            You are testing the OpenVPN server from the outside right?

            Chattanooga, Tennessee, USA
            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
            Do Not Chat For Help! NO_WAN_EGRESS(TM)

            1 Reply Last reply Reply Quote 0
            • V
              viragomann
              last edited by

              Yes, I know the reply-to function of pfSense, but in a manner of speaking I'm in doubt, that it works well in any set up. Often it seems that response packets are replied to the default gateway though.

              1 Reply Last reply Reply Quote 0
              • DerelictD
                Derelict LAYER 8 Netgate
                last edited by

                It works every time. If it does not, it means that some other condition is present that is preventing reply-to from being added to the state.

                Chattanooga, Tennessee, USA
                A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                Do Not Chat For Help! NO_WAN_EGRESS(TM)

                1 Reply Last reply Reply Quote 0
                • M
                  mdahal
                  last edited by

                  Hi Derelict and viragomann,

                  Thank you for your responses. Yes I am testing from outside.

                  Just tried using do not pull routes. Disabled interfaces and re-enabled interface and it seems to be working now.

                  Really appreciate your help!!

                  Regards,
                  mdahal

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