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

    OpenVPN site-to-site multi-WAN

    OpenVPN
    6
    20
    14.3k
    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

      "Default Gateway Switching" allows the internals of the pfSense box to find a fail over path to the internet - e.g. GUI functions that go to the internet to look something up (updates availability, available package list) or ordinary "ping" from the command line.
      The code does check that it is not about to switch the default gateway to LAN. But I guess it has to just pick another interface that is up and hope it leads somewhere useful. It seems to work fine on simple configs, like having 1 LAN and 2 WAN.
      I tried to find a way to add rules to feed this stuff into a gateway group - e.g. a floating rule feeding anything from 127.0.0.1, WAN Address into a gateway group. But no joy, I guess this local traffic never made it into the pf system to get filtered and policy routed? Or did I miss something in my setups?
      Is there a way to get the internal traffic generated in the box to feed into a gateway group and be policy routed?

      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
      • C
        cmb
        last edited by

        @phil.davis:

        Is there a way to get the internal traffic generated in the box to feed into a gateway group and be policy routed?

        yes, with quick floating rules

        1 Reply Last reply Reply Quote 0
        • R
          rockcreektech
          last edited by

          Phil's way seems to be working very well or me. I've done various combinations of unplugging gateways at each end, and traffic seems to flow just fine no matter what. It also seems to automatically go back to the main gateway when it is plugged back in. I guess my simple configuration (pretty much identical to Phil's in every way) doesn't do anything to confound the limitations of the default gateway switching option.

          On 2.1 you can (once all the code is finished) select a gateway group for the client (and/or server's) "Interface" and it can failover that way.

          I'm very much looking forward to that. How long do you think it will be before that's available Jimp?

          1 Reply Last reply Reply Quote 0
          • H
            hcoin
            last edited by

            So, maybe it's a mistaken half-newbie intuition but–

            Why not port forward the various OpenVPN target ports on all the variously available WAN interfaces to 'localhost', have PF's openvpn listen only on 'localhost' using the various ports for the various client types without regard to route?  Be sure the option that routes traffic out the port it came in on is checked, and --- viola?  Yes?  No?

            1 Reply Last reply Reply Quote 0
            • R
              rockcreektech
              last edited by

              @jimp:

              On 2.1 you can (once all the code is finished) select a gateway group for the client (and/or server's) "Interface" and it can failover that way.

              So if I'm not mistaken, wouldn't that completely eliminate the need for OSPF? I'm trying really hard to avoid using beta packages in this particular production environment because so much is at stake. Not to mention I'm never quite sure if I've got OSPF configured correctly. It's very new to me.

              @hcoin:

              Why not port forward the various OpenVPN target ports on all the variously available WAN interfaces to 'localhost', have PF's openvpn listen only on 'localhost' using the various ports for the various client types without regard to route?   Be sure the option that routes traffic out the port it came in on is checked, and –- viola?  Yes?  No?

              That's basically what Phil's done. Traffic on the OVPN ports was NAT'd to the LAN IP and then listening is done on the LAN interface without regard to route. Although, I'm not sure what "option that routes traffic out the port it came in on" you're referring to.

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

                @rockcreektech:

                So if I'm not mistaken, wouldn't that completely eliminate the need for OSPF? I'm trying really hard to avoid using beta packages in this particular production environment because so much is at stake. Not to mention I'm never quite sure if I've got OSPF configured correctly. It's very new to me.

                In my environment, we have a group of half a dozen main offices that have a full-mesh of OpenVPN links between them all. So from any of these offices, any other office can be reached directly across a single OpenVPN link. If your network is manageably small like that, then you can have the full-mesh of OpenVPN links. By entering local and remote network CIDR on the OpenVPN links you get a complete routing table for your private intranet - no need for OSPF.
                Then I add a small branch office. It sends 99% of its data to 1 partner office, so I just make 1 OpenVPN link to that office. But so that it can also reach other offices occasionally, I have to add:
                a) "route" commands in the advanced section on the branch office client, telling it that the OpenVPN link is the way to a bunch of other office subnets also.
                b) at each other office, saying that the way to "branch office" is via "partner office".
                Once this happens more than a couple of times, you start to think it would be nice to run something like OSPF - then the routes to parts of the private network that are not full-meshed can be learnt automatically. It all depends how complicated your private network topology is and how often it changes.

                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
                • C
                  connectfarrukh
                  last edited by

                  Hi everyone,

                  I am just trying to follow the post and I am not too much technical in terms of all this VPN and Failover. In my case, I have the following locations and desired configuration;
                  Head Office

                  • Lan = 10.60.1.0/24
                  • DMZ = 192.168.2.0/24
                  • Wan 1 = xxx.xxx.xxx.xxx/30 (Data Link without Internet)
                  • Wan 2 = xxx.xxx.xxx.xxx/30 (Data Link without Internet)
                    Branch 1
                  • Lan = 10.60.2.0/24
                  • Wan 1 = xxx.xxx.xxx.xxx/30 (Data Link without Internet)
                  • Wan 2 = xxx.xxx.xxx.xxx/30 (Data Link without Internet)
                    Branch 2 - (Newly Upcoming)
                  • Lan = 10.60.3.0/24
                  • Wan 1 = xxx.xxx.xxx.xxx/30 (Data Link without Internet)
                  • Wan 2 = xxx.xxx.xxx.xxx/30 (Data Link without Internet)

                  Normally, with a Single WAN link HO->Br-1 is connected over VPN and everything is fine and working. I wanted to follow the post to configure (Automatic Failover on MultiSite with Dual Wan over OpenVPN) Automatic Failover for VPN on both end i-e Head Office and Branch plus same for the newly upcoming branches.

                  My questions are;

                  • Is that post and configuration workable for more than 1 Client?
                  • How do I configure the next coming Branches? and What will be the VPN Configuration of Newly coming branches?

                  Thanking you in advance for any coming help!!

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

                    Since this post, 2.1-BETA1 has added:
                    a) the ability to a list of networks in the Local Networks and Remote Networks fields of OpenVPN Server/Client. You do not need to put "route" or "push route" statements in the advanced box any more.
                    b) OpenVPN Client can use a Gateway Group instead of a particular interface - so no need to bother with the default gateway switching business, or other trickery to convince the client thta it has multiple ways out to the internet.
                    c) OpenVPN Server can listen on a Gateway Group - I haven't used that, I still port forward to LAN and make my server listen on LAN. But the Gateway Group listen should allow you to have the server listening just on the highest-priority interface in the Gateway Group. That way the server should fail-back when the high-priority WAN interface comes back up after a failure.

                    As I installed more pfSense at remote offices I ended up with lots of OpenVPN servers at my main offices - call them M1 and M2 - every branch office had 2 clients, connecting to M1 and M2. After 5 or 6 of these I decided to change to Peer-to-Peer SSL/TLS - that allows me to have just 1 server at M1 and 1 server at M2. With Client-specific overrides I can tell the server what remote office subnet is at the end of which connection. The routing failover principles apply just the same to the PSK or SSL/TLS security method.

                    You choose if you want to make a new PSK server to listen for each branch office, or 1 SSL/TLS server to listen for all offices.

                    This post has more interesting discussion: http://forum.pfsense.org/index.php/topic,59656.0.html

                    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
                    • C
                      connectfarrukh
                      last edited by

                      Hi Phil,

                      One more time, need a little help. With the said Guide, I followed the exact procedure. VPN established and net-to-net + DMZ all are working fine. But when I dis-connected WAN to test Failover to OPT-1, it's not establishing connection. OpenVPN Logs on server has following error lines:

                      Feb 22 03:13:19
                      openvpn[18246]: Authenticate/Decrypt packet error: packet HMAC authentication failed

                      Feb 22 03:13:21
                      openvpn[18246]: Authenticate/Decrypt packet error: packet HMAC authentication failed

                      Feb 22 03:13:23
                      openvpn[18246]: Authenticate/Decrypt packet error: packet HMAC authentication failed

                      Feb 22 03:13:31
                      openvpn[18246]: Authenticate/Decrypt packet error: packet HMAC authentication failed

                      Feb 22 03:13:32
                      openvpn[18246]: Authenticate/Decrypt packet error: packet HMAC authentication failed

                      Feb 22 03:13:43
                      openvpn[18246]: Authenticate/Decrypt packet error: packet HMAC authentication failed

                      Feb 22 03:13:43
                      openvpn[18246]: Authenticate/Decrypt packet error: packet HMAC authentication failed

                      and OpenVPN logs on Client has:

                      Mar 13 10:48:36 openvpn[12597]: Inactivity timeout (–ping-restart), restarting
                      Mar 13 10:48:36 openvpn[12597]: SIGUSR1[soft,ping-restart] received, process restarting
                      Mar 13 10:48:38 openvpn[12597]: NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
                      Mar 13 10:48:38 openvpn[12597]: Re-using pre-shared static key
                      Mar 13 10:48:38 openvpn[12597]: Preserving previous TUN/TAP instance: ovpnc3
                      Mar 13 10:48:38 openvpn[12597]: UDPv4 link local (bound): [AF_INET]10.60.3.21
                      Mar 13 10:48:38 openvpn[12597]: UDPv4 link remote: [AF_INET]192.168.31.34:1194

                      Any Idea/Help appreciated.

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

                        The server errors are really old and I do not think related to your current problem, so I will ignore them.
                        It seems that the client is simply not getting through to the server at all.

                        Mar 13 10:48:38   openvpn[12597]: UDPv4 link local (bound): [AF_INET]10.60.3.21
Mar 13 10:48:38   openvpn[12597]: UDPv4 link remote: [AF_INET]192.168.31.34:1194

                        From the above, the client is correctly bound to a LAN IP at Branch2.
                        For some reason it thinks it should connect to the server on 192.168.31.34 - which is a private IP. Unless you have setup a completely private test environment, then that is not a valid address of the server.
                        If the client is setup correctly, with an extra "remote" statement in the advanced box, then the client log should cycle around about every minute trying
                        "UDPv4 link remote: [AF_INET] n.n.n.n:1194" and
                        "UDPv4 link remote: [AF_INET] m.m.m.m:1194"
                        where n.n.n.n and m.m.m.m are the 2 WAN IPs at the server end.
                        Both those server WAN IPs should be port-forwarded to LAN on the server end, where the server should be listening.
                        What did I misunderstand about your setup?

                        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.