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

    Routing problems for OpenVPN on second instance.

    Scheduled Pinned Locked Moved OpenVPN
    6 Posts 3 Posters 555 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.
    • M
      mspies
      last edited by

      I have two instances of OpenVPN running on my appliance currently. My first instance I have no issues with. However, on my second instance, any client that receives an address higher than the first available in the subnet pool, traffic will not be returned. The two instances

      Connecting to instance 2, if I get the first address in the pool I can start a ping to an endpoint and get a response. Doing a packet capture I see the traffic in both directions, from the VPN client to the endpoint and the return. I am capturing at the OpenVPN interface in the webUI.

      If I am not the first address in the pool, and send the same ping, I do not see the response to the ping running the same packet capture. If I capture at the next interface I see the packets in both directions. This leads me to believe that for some reason the packets are being dropped before being sent out to the VPN client.

      From what I can tell, re-rooting/rebooting is the only thing that seems to resolve this. I am currently running version 2.4.4-Release-p3 as I have not had time to validate 2.4.5 in my lab yet. This issue does seem to exist in my lab, but the requirements were not met before today when I explicitly tried it. I will apply the 2.4.5 update to see if that remedies my issues currently, but am curious if anyone else has this issue, or knows of a workaround for it.

      Thanks

      1 Reply Last reply Reply Quote 0
      • Z
        Zawi
        last edited by

        are you connecting by using same user?

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

          I was for testing. I have the option to allow multiple connections by the same user.

          In production this issue came up after 2 separate users connected at the same time. The only thing that would determine who functioned and who didn't was who got the lowest available address.

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

            Logging in this morning my lab is working after the update. Unfortunately, since it took a full reboot, I cannot confirm if the update or a reboot resolved my issue. I will have to follow up in a few days to see if behavior has changed.

            1 Reply Last reply Reply Quote 0
            • B
              Brow98n
              last edited by Brow98n

              You are basically trying to set two default gateway. Even if you could add both routes, only one of them would work correctly!

              M 1 Reply Last reply Reply Quote 0
              • M
                mspies @Brow98n
                last edited by

                @Brow98n In what scenario am I attempting to set 2 default routes? I am thinking an assumption was made here, probably due to my bad explanation of the problem.

                When I log in twice with the same user it is from different machines as I would not be able to easily determine which tunnel was broken. I do not have OpenVPN overwrite the default route on the client, I just advertise routes to specific endpoints inside my networks. I do not believe that OpenVPN easily supports a per user route advertisement, AFAIK, it is a function of the OpenVPN instance. In the end, if I can give routes to device list A to user list A and device list B to user list B, that would accomplish my goal of 2 instances, and work around my issues I have on the second instance.

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