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

    OpenVPN - using a gateway group as the interface

    Scheduled Pinned Locked Moved
    2.1 Snapshot Feedback and Problems - RETIRED
    3
    9
    6.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.
    • P
      phil.davis
      last edited by

      Today I am working on trying and testing failover setups for OpenVPN site-to-site links between multi-WAN sites. I noticed that some code has been committed that allows an OpenVPN server interface to be a gateway group.
      Currently I have been forwarding a port (e.g. 4567) from both my WAN and OPT1 to LAN. Then the OpenVPN server interface is set to LAN and port 4567. In this configuration, clients can come from outside to either the WAN or OPT1 address - they have an extra "remote" line in their OpenVPN config so the client tries 2 IPs for the server, connecting to the first one they find that is up. The OpenVPN server can just listen on LAN and get all the incoming connects from WAN and OPT1. This provides server-side redundancy.

      1. Is the gateway group functionality meant to make this easier? If I select a gateway group as the interface for an OpenVPN server, then what does it do:
        a) Listen on all interfaces in the gateway group? (functionally similar to the port forwarding method above.)
        b) Listen on the highest-priority interface that is up, switching its listening as interfaces come up and down?
        c) Something else?

      On the client side, at a client site with multi-WAN available, I would really like the client to be told to exit to the internet via any of a list of interfaces - i.e. to use a gateway group. Conceptually, the client could attached itself to the highest-priority member that is up in the gateway group. In real-time, if the client-server connection drops out, then the client would choose again from the gateway group and start trying to originate an OpenVPN link using the next available interface. If this functionality is possible, then a truly redundant site-to-site link can be made with just 1 client and 1 server - the server is effectively listening on both its WANs, the client is able to select which WAN it uses to exit its own site, and to try each of the server addresses until it finds one that is up. Then there will always be just a single logical link between the sites, making the routing setup easy.

      Is it feasible to do something like this for clients and gateway groups?

      As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
      If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

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

        b and yes

        1 Reply Last reply Reply Quote 0
        • P
          phil.davis
          last edited by

          Doing 1(b) the server is just listening on 1 of the working interfaces at any time.
          So the client still needs to try a list of possible IP addresses that the server might be on (easy to do in the client config with extra "remote n.n.n.n port" options). I can't think of an easy way for the client to know which WAN/OPT1 address the server will be listening on.
          But selecting a gateway group for a server interface saves messing about doing the NAT port forwarding from WAN and OPT1 into LAN. And it means that the server will be listening on the highest priority WAN that is up, and thus clients will only be able to connect through that WAN - so the load-balancing/failover behaviour is more flexibly defined by the gateway group parameters.

          Is client outgoing connect by gateway group coming soon?

          As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
          If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

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

            It's on the roadmap for a commercial client. You would normally couple the VPN server name to a dynamic DNS entry.

            Did you know that we also support gateway groups for a dynamic dns entry now?

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

              For the server side, I'd still consider the port forward method as safer for UDP if you want to connect to all wans at the same time.

              Otherwise the return traffic will go back by whatever gateway is default when it's bound to 'any' interface.

              If it's bound to a single interface (or a gateway group so it's listening to one at a time) then it would be OK, but you can only connect to whichever one is active at the moment.

              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
              • P
                phil.davis
                last edited by

                I had a play with Gateway Groups and Dynamic DNS - found 1 little bug which I fixed on Github. This should be useful to make OpenVPN Servers listen on a prioritised interface. Having Dynamic DNS allows the remote client to find out which IP address the OpenVPN Server is currently listening on. It means that when the high-priority interface goes down and up again, the OpenVPN Server will fail over and then fail back. That is useful for installations where we want the OpenVPN Server to listen mostly on a main interface, and only fall back to a 2nd (probably slower) interface as a backup.
                I tested the Dynamic DNS fail over - the external IP address changes over and back again as the main link goes down and up.
                I haven't tested the OpenVPN Server, I'll have a go at that at some convenient time…

                As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
                If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

                1 Reply Last reply Reply Quote 0
                • P
                  phil.davis
                  last edited by

                  I noticed that, on the latest snapshot, the OpenVPN Client Interface can be a Gateway Group. I gave it a try. I have a gateway group that has WAN as Tier1 and OPT1 as Tier2 - called WANfirst. I selected WANfirst as the interface for the OpenVPN Client. It started up fine, and the server end showed it connected from my WAN IP.
                  I also have DynamicDNS setup on WANfirst Gateway Group, so I can watch the DNS name to IP address and see the failover.
                  Pulled the plug on my WAN connection.
                  Dynamic DNS address happily changed to my OPT1 IP address.
                  OpenVPN Client tried to reconnect (because it lost its current path to the other end anyway). But it still bound itself to the WAN IP. There didn't seem to be anything that reconfigured it to bind to OPT1 IP.
                  If I just restart the OpenVPN Client from Services, it doesn't help - still binds to WAN.
                  If I edit the OpenVPN Client entry, don't change anything and save, the system re-analyses the state of WANfirst Gateway Group and selects OPT1 and binds the client to that IP address. Then it works.
                  Then I reconnect WAN. Dynamic DNS changes back to WAN IP - good stuff. But there is nothing that tells the OpenVPN Client to bind to WAN now, so it does not fail back. When I pull the plug on OPT1, the OpenVPN link is dead again.

                  I am just reporting this so the developers know what happens - I guess the GUI has been updated and now the code underneath to implement the failover and failback is still coming?

                  I have some logs I can post if needed - but if the code is just not there yet, then there is no need for looking at logs!

                  As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
                  If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

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

                    We still need to hook a openvpn reconfigure in the apinger reload command

                    1 Reply Last reply Reply Quote 0
                    • P
                      phil.davis
                      last edited by

                      I thought I saw some more code committed, so updated to:
                      2.1-BETA0 (i386)
                      built on Tue Jul 3 17:55:06 EDT 2012
                      FreeBSD 8.3-RELEASE-p3

                      Made an OPT1first gateway group, with OPT1 as tier1, WAN as tier2. Configured the OpenVPN client for interface OPT1first. Client connects out OPT1. Then before I tried any failover testing, the ISP on OPT1 went down - very convenient, it's not every day that you thank your ISP for a failure. OPT1 status was down. But the OpenVPN client did not move over to WAN. It seemed to remain stuck trying to escape out OPT1.

                      So I guess there is not enough code there just yet to support this, or it needs tweaking.

                      As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
                      If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

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