Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 1 subscriber
  • Views 50518 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

site-to-site VPN redundancy

Mast_01
Hello,
i'd like to refloat an old "issue" i've had that haven't managed to check the current v9 version support for it:
Site to site VPN with multiple uplinks.

for example: i have two sites A and B, each site has 2 separate ISPs(mix of fixed/dynamic IPs/NATted)
Tunnel must be up at all times regardless of which ISP fails, convergence time should be in seconds.

currently i have this setup with a couple of sonicwall appliances as they specifically support secondary remote gateway on the tunnel definition(you define the main one and a backup one) and has proven to work, but i find the platform itself quite crappy apart from that (it's counter intuitive and the "visibility" is quite poor).

So, does UTM support such scenario currently?.
or do i need to create 4 tunnels (A1-B1, A1-B2, A2-B1, A2-B2) and go?
and god knows what happens with traffic loops/routing/addressing in that scenario?


This thread was automatically locked due to age.
Parents
  • 0

    Auto-Failover IPsec VPN Connections

    Note: See my EDIT at the bottom of this post for a more complex solution with instant failover.

    Interface Groups are created on the 'Interfaces' tab in 'Interfaces & Routing'.  No Multipath rule is required.  These new groups are nifty.  I used them in a recent project to connect four remote offices to a central UTM.

    Each office has two, different WAN connections.  I configured one Interface Group for a VoIP VPN that started on one WAN connection and another Interface Group for a Data VPN that started on the other.  If any one WAN connection goes down, the VPN on that connection fails over to live on the other connection with the other VPN.  I also added some QoS rules to minimize the VoIP connections getting hammered if the Data VPN ever failed over to the VoIP-preferred line.

    Cheers - Bob
    PS So, with this approach, Post #4 above would look like:

    On both sides, create an Interface Group named "VPN Group" to be used as the 'Local interface' in the IPsec Connection definition on both sides.

    Site A:

    VPN Group = WAN-Site-A-1, WAN-Site-A-2
    Remote Gateway for Site B uses a Gateway that is an Availability Group with, in order, WAN-Site-B-1, WAN-Site-B-2

    Site B:

    VPN Group = WAN-Site-B-1, WAN-Site-B-2
    Remote Gateway for Site A uses a Gateway that is an Availability Group with, in order, WAN-Site-A-1, WAN-Site-A-2

    Notice that the first Host in each Availability Group must be the IP of the WAN interface in the top position of "VPN Group" on the other side.

    ------------------

    EDIT 2017-10-08: V9 brought us the ability to bind an IPsec Connection to an Interface, so it's now possible to have two active tunnels and instant failover using Static Routes.  The best description I know of this is in German, but Sophos UTM multiple S2S IPsec VPN mit Failover – Tutorial (DE) has pictures of all settings in English.

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply
  • 0

    Auto-Failover IPsec VPN Connections

    Note: See my EDIT at the bottom of this post for a more complex solution with instant failover.

    Interface Groups are created on the 'Interfaces' tab in 'Interfaces & Routing'.  No Multipath rule is required.  These new groups are nifty.  I used them in a recent project to connect four remote offices to a central UTM.

    Each office has two, different WAN connections.  I configured one Interface Group for a VoIP VPN that started on one WAN connection and another Interface Group for a Data VPN that started on the other.  If any one WAN connection goes down, the VPN on that connection fails over to live on the other connection with the other VPN.  I also added some QoS rules to minimize the VoIP connections getting hammered if the Data VPN ever failed over to the VoIP-preferred line.

    Cheers - Bob
    PS So, with this approach, Post #4 above would look like:

    On both sides, create an Interface Group named "VPN Group" to be used as the 'Local interface' in the IPsec Connection definition on both sides.

    Site A:

    VPN Group = WAN-Site-A-1, WAN-Site-A-2
    Remote Gateway for Site B uses a Gateway that is an Availability Group with, in order, WAN-Site-B-1, WAN-Site-B-2

    Site B:

    VPN Group = WAN-Site-B-1, WAN-Site-B-2
    Remote Gateway for Site A uses a Gateway that is an Availability Group with, in order, WAN-Site-A-1, WAN-Site-A-2

    Notice that the first Host in each Availability Group must be the IP of the WAN interface in the top position of "VPN Group" on the other side.

    ------------------

    EDIT 2017-10-08: V9 brought us the ability to bind an IPsec Connection to an Interface, so it's now possible to have two active tunnels and instant failover using Static Routes.  The best description I know of this is in German, but Sophos UTM multiple S2S IPsec VPN mit Failover – Tutorial (DE) has pictures of all settings in English.

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Children
  • 0 in reply to BAlfson
    Thanks for the clarity Bob. However, I have one more issue, the recommendation is to config the branch offices to respond only mode on the vpn gateway. If I do that, where would I use the Availability group? I have tried it both ways and got the vpn to come up only when the branch is in respond only, when I set it to initiate and use the availability group it does not connect. Maybe it's because of the existing multipath rule? I can't break that until the weekend. I have 12 sites connected the old fashioned way. On the other hand, I can see from the ipsec log that the 2 branches are connecting over the underutilized interface, so spreading using the interface group on the home site is working, just not sure about failover.
Unfiltered HTML