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

    IPSec VPN & load balancing with two DSL connections

    Scheduled Pinned Locked Moved IPsec
    3 Posts 2 Posters 340 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.
    • C
      cre8toruk
      last edited by

      Hi All, I have a netgate running PFSense and have successfully setup Ipsec VPN tunnels which is working great.
      I have two DSL connections which are configured in two gateway groups and are assigned to different traffic types. I assume in an active passive way.

      With all the COVID-19 stuff going on we're looking to get some people working from home and I was wondering if it was possible to set the IPSEC vpn tunnels to work on a load balance of the two DSL connections?

      Is there a guide somewhere on how to do that?

      Apologies if that's a bit of a ramble happy to clarify :-).

      Paul.

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

        The tl;dr answer is: Not effectively. Not for IPsec.

        To load balance across two IPsec tunnels you would need a several things things. Note that this assumes pfSense on both ends.

        1. Tunnels setup using routed IPsec on both tunnels on both ends (VTI, assigned interfaces, etc)
        2. Gateway groups using equal tier values for both routed IPsec tunnel interface gateways
        3. Policy routing rules setup on the LAN(s) directing traffic for the VPN to use the gateway group

        One of either:

        4a. Return routing to ensure that packet replies go back out the interface they entered -- This is where it breaks down the most, since on FreeBSD, the reply-to feature of pf doesn't work on IPsec interfaces. Without this, traffic will always return over one interface (whichever has a static route back to the remote end)
        4b. NAT on the IPsec interfaces so the remote side will send the traffic back the expected path -- NAT+VTI have some issues, but this may work in some cases, but it adds NAT which would break some protocols which otherwise would work inside a VPN

        As you can probably tell from that, even if it did work, it also doesn't scale well to multiple remotes, since you'd need another pair of tunnels+interfaces+gateways+rules for every peer, and definitely isn't an option for mobile IPsec.

        You can use multiple links for site-to-site redundancy by ditching the policy routing and using a dynamic routing protocol like BGP or OSPF to manage the routes and failover.

        Another potential workaround doesn't involve VPNs at all: If both your links are from the same ISP, and the ISP supports MLPPP, you may be able to setup MLPPP bonding so both DSL connections are aggregated into a single virtual link which could potentially use the sum total of both circuits in bandwidth. But that 100% depends on your ISP supporting it.

        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!

        C 1 Reply Last reply Reply Quote 0
        • C
          cre8toruk @jimp
          last edited by

          @jimp thanks for the tips. I think that's a bit complicated for our needs certainly right now and certainly last minute like it currently is.

          Any ideas why I can't create another ipsec tunnel and point it at the other dsl connection ? I mean I can but the authentication options don't allow me to point it at my radius. I only have Mutual PSK and Mutual (something else) as options in the drop down....

          I had hoped I could set up another ipsec tunnel tied to the second DSL connection, but it doesn't seem to let me.

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