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

    BOUNTY: IPSec VPN TUNNEL REDUNDANT 1K$ USD

    Scheduled Pinned Locked Moved Expired/Withdrawn Bounties
    19 Posts 11 Posters 16.4k 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.
    • B
      billm
      last edited by

      ifstated might be an option here - I don't see a good way to implement this in pfSense so it's generic enough for broad use though.  I can see how to make this work, obviously you have to be checking link (and tunnel) status and tear down the SPDs for the WAN tunnel on failover and recreate those SPDs to the OPT1 interface.  That takes care of one end…the other end is trickier, how do you allow this new random IP coming in....obviously you can't lock the tunnel down to IPs (and thus ends the research I've done :))

      --Bill

      pfSense core developer
      blog - http://www.ucsecurity.com/
      twitter - billmarquette

      1 Reply Last reply Reply Quote 0
      • O
        ollopa
        last edited by

        The tunnel is set up for mobile clients, so it doesn't matter that the other end's IP address changes.

        But the problem remains that a tunnel has to be torn down and a new one brought up.  It's possible to have a daemon detect failover and respond accordingly, but the process is by no means seamless or instantaneous.

        Also a route can go down without an interface going down.  Some routing protocol should be used to detect when the route is down rather than when the interface is down.

        I see that ifstated can use pings to detect if a route is down, so this could work.

        It's not instantaneous, however, because of the lag while waiting for a new tunnel to be established.

        1 Reply Last reply Reply Quote 0
        • J
          jeroen234
          last edited by

          will this work with ipsec for fall over?

          server1                                                                              server2
          lan 10.141.251.1  -> wan 80.1.1.1            vpn1  wan 60.90.12.23 -> 10.142.251.1 lan
          vip on lan 10.141.251.2 ->  wan 80.1.1.1 vpn2  opt1 60.91.125.243  -> 10.142.251.2 vip on lan

          routes on server1:
          route add 10.142.251.0/24 gateway 10.142.251.1 metric 0  (vpn1 as default vpn)
          route add 10.142.251.0/24 gateway 10.142.251.2 metric 50 (vpn2 as fallover vpn)

          routes on server 2:
          route add 10.141.251.0/24 gateway 10.141.251.1 metric 0  (vpn1 as default vpn)
          route add 10.141.251.0/24 gateway 10.141.251.2 metric 50  (vpn2 as fallover vpn)

          1 Reply Last reply Reply Quote 0
          • O
            ollopa
            last edited by

            It doesn't work because you can't bring two simultaneous tunnels up for the same traffic…

            There are all sorts of issues with racoon crashing also when trying to do failover tunnels on the same box.  I wasted a full day writing scripts to manage the failover and testing this out.  Basically it is possible in theory, but the FBSD implementation of IPsec doesn't allow it work in practice.

            The best way to do it right now is with three machines.  Two to set up the tunnels and one to manage the failover/load balacing (if desired).
            A one-box solution does not work reliably or seamlessly on FBSD, let alone PFsense!

            1 Reply Last reply Reply Quote 0
            • S
              sbyoon
              last edited by

              I'd like to keep this bounty but I already supplied my client with another solution for IPSec failover. So now I don't need this function actually. But I believe I will need this function for future. So I will reduce the mony to $100 and I will keep this bounty. I think somebody can add some more bounty for this function.

              Thanks to pfsense developers and especially thanks to Ollopa.

              1 Reply Last reply Reply Quote 0
              • valnarV
                valnar
                last edited by

                What was the other solution that you found?

                Robert

                1 Reply Last reply Reply Quote 0
                • T
                  tunge2
                  last edited by

                  @valnar:

                  What was the other solution that you found?

                  Robert

                  I want to know it to….

                  1 Reply Last reply Reply Quote 0
                  • S
                    sullrich
                    last edited by

                    IPSEC failover works TODAY on 1.0 using CARP + IPSEC Failover feature.

                    I have been using well before 1.0 was released at my work.  2 firewalls.  When the first firewall goes down, all IPSEC traffic still works.    I have gone over the setup many times in the forum.  No scripts needed, nada, it just works.

                    1 Reply Last reply Reply Quote 0
                    • S
                      sbyoon
                      last edited by

                      Sorry for late reply.

                      I've used other dual wan router in front of pfsense. The dual wan router has a fail over fuction. And I made a script for re-establishing ipsec on pfsense when the failing-over occurs on dual wan router.

                      What I want is not box redundant. What I want is fail over internet line with ipsec.
                      Pls read my earlier post.

                      I'm continuing test for this funtion with pfsense snapshot. But until now it does not work. The main prblem that should be solved first is that ipsec does not work at second wan(opt1).

                      Thanks.

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

                        I think it should work if you add a static route through the OPT-WAN to the remote endpoint. Maybe you can integrate this in your script and test. If this works we maybe could integrate it into the linkdown detection code (no promise though).

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

                          I have managed to get IPSEC over OPTx working correctly.  I've been testing it on the 3-27-07 updates and .iso's for the full version install.  Here is what I've done to make it work:

                          1.  I created the IPSEC definitions on the IPSEC page and chose the OPTx interface that I want to use.
                          2.  I created manual rules for the desired OPTx interface to allow IPSEC traffic to connect to the IP of the pfsense box on that Interface.  Specifically, I created rules to allow UDP 500, ESP, AH, and GRE to connect to the Public IP on the OPTx interface.

                          Note, I am using static IP's on all of my WAN type interfaces.  All of the routers in front of me are operating in bridged mode and do not do any port forward filtering or NAT type stuff, so if you have private IP's on your OPTx interfaces and the routers in front of them are doing any sort of port forwarding or NAT, you may run into tunnel stability problems.

                          Vaughn

                          1 Reply Last reply Reply Quote 0
                          • S
                            sullrich
                            last edited by

                            It should be creating the rules on the OPT interfaces behind the scenes but there is a bug preventing it.  I am aware of the bug but this week has been nonstop madness at my day job and other engagements that have prevented me from fixing it.

                            1 Reply Last reply Reply Quote 0
                            • S
                              simonc
                              last edited by

                              @sullrich:

                              It should be creating the rules on the OPT interfaces behind the scenes but there is a bug preventing it.  I am aware of the bug but this week has been nonstop madness at my day job and other engagements that have prevented me from fixing it.

                              There is any solutions now ?

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