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

    On-demand IPsec fallback connection

    Scheduled Pinned Locked Moved Routing and Multi WAN
    1 Posts 1 Posters 449 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.
    • T
      towo
      last edited by

      Hi there, I'm currently tinkering with adopting a so-far manually managed failover connection into a more automatic one.

      The edge conditions are as follows. I have two sites, let's just call them Alpha and Bravo. Alpha has 172.17.0.0/16 (as well as 172.18.0.0/16) and Bravo has 172.16.0.0/16.

      There's an MPLS connection between both sites, reachable via 172.(17|16).1.100, respectively.

      We also have an IPsec connection that's bolted on in case of a fallback, using the regular WAN connections of Alpha and Bravo.

      What I want is: if the MPLS cross-site goes down, use the IPsec tunnel for cross-site connections.

      Thus far, I've come up with the following:

      • Create gateways for MPLS and IPsec

      • Create a gateway group over both

      • Use monitoring IP from 172.16/16 for both GWs.

      • Shunt traffic into the GG using pf rulesets

      Some potential problems:

      • I can only create one static route for 172.16.0.0/16. Should I

        • put it on the MPLS?

        • leave it away as it will be ignored by the FW rules?

        • something entirely different?

      • I can't use the same monitor IP for two gateways. Is there a better solution? The MPLS may still be down even though the router pings, for example.

      • Does the monitoring actually use the gateway for pinging? Or is that attempt nonsensical?

      • Will the IPsec due to policy routing just shunt everything else out of the way?

      I'm feeling like I'm missing a vital trick here, any pointers - or better solutions for a redundancy failover of this kind - are appreciated.

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