Navigation

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

    Change OpenVPN port on the fly

    OpenVPN
    3
    6
    1153
    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
      mjohnson last edited by

      I have done some searching and some (unsuccessful) testing to change the port that the OpenVPN clients connect to on the fly. The reason we are looking at changing it on the fly is because we have hundreds of users and changing each config individually would be a tedious task to say the least.

      Is this possible? I realize if I change the port users won't connect, but I am wondering about configuring a parallel server and somehow pushing the new port to clients when they connect to the old server.

      1 Reply Last reply Reply Quote 0
      • D
        divsys last edited by

        What is the actual problem you're trying to solve?

        Having hundreds of users potentially connecting to OpenVPN is not necessarily a problem as long as you have capacity to handle them all.

        You can have more than one OpenVPN server on pfSense, but the port used by the individual clients is coded into the client config so you're still stuck with updating the clients indvidually.  There may be a way to point the clients at an update package/script that gets activated when they connect so that they are pointed to a new port when they connect next time - something like a staged update.

        Why do you want to change ports?

        -jfp

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

          Capacity isn't an issue as the users have the VPN for "just in case" scenarios. It's very rare that many are connected at once. We are changing the ports because we have encountered a few locations that will not permit the traffic of the client, so the only solution I can come up with is to change the port to something that likely will not end up being blocked. It's rare, but when it does happen the end users scream like crazy- so I want to just head it right off.

          I am suspicious we will just have to bite the bullet and send out instructions with a config download link to the new configurations. This ought to be interesting…

          1 Reply Last reply Reply Quote 0
          • D
            divsys last edited by

            If the only thing that changes for the remote link is server's access port, you should have a number of less obtrusive ways to update the end user's config file.

            The standard Client Export package will let you split out the *.ovpn text file for the end users so you should be able to send a small batch update to simply overwrite the existing file.  For the really daring types, you can edit the port number in the ovpn file directly  ::)

            As mentioned earlier you should be able to keep the OpenVPN server instance running on two (or more) different ports at the same time so you can accommodate different types of client connections.

            You might try adding an "Emergency connection" to their standard configured package so that the end users have something to try when all else fails.  "Regular" users would just connect as they always have.

            -jfp

            1 Reply Last reply Reply Quote 0
            • jimp
              jimp Rebel Alliance Developer Netgate last edited by

              By far the easiest way to do this is to use port forwards.

              Change the server to bind to localhost on whatever port you want then add port forwards for every port you want the VPN to respond on, they can all be handled by one instance. Current clients can keep hitting the old port as needed and new ones can use a different port (or both).

              Next time you export choose one of the automatic options that use port forwards to form remote lines, it will add in multiple lines so clients will rotate and try different ports automatically if one fails.

              Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

              Need help fast? Netgate Global Support!

              Do not Chat/PM for help!

              1 Reply Last reply Reply Quote 0
              • D
                divsys last edited by

                Very nice solution!

                Much more elegant than my brute-force approach  :)

                -jfp

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post