Interesting one which I believe SHOULD have a simple answer however I am struggling here!
I have a customer with the below environment (IP addresses are not the originals):
1 x SMS (This SMS manages both clusters defined below and sits behind GW-Cluster-A. i.e. it manages GW-Cluster-B over the internet but GW-Cluster-A via the internal network)
GW-Cluster-A (2 x 5000 appliances)
|eth2 (Microwave1 P-2-P)||10.10.10.1/24||10.10.10.2/24||10.10.10.3/24|
|eth3 (Microwave2 P-2-P)||10.10.20.1/24||10.10.20.2/24||10.10.20.3/24|
GW-Cluster-A (2 x 1500 SMB appliances - NB!!!)
|eth2 (Microwave1 P-2-P)||10.10.10.4/24||10.10.10.5/24||10.10.10.6/24|
|eth3 (Microwave2 P-2-P)||10.10.20.4/24||10.10.20.5/24||10.10.20.6/24|
The requirement is for a site-to-site VPN to be established between both GW-Cluster-A and GW-Cluster-B utilising eth0 as the primary VPN interface and eth2 and eth3 as backup VPN interfaces.
1. Primary VPN over: eth0 on both clusters
2. Backup VPN 1 over: eth2 on both clusters
3. Backup VPN 2 over: eth3 on both clusters
This in theory should be pretty straight-forward using Link Selection. The issue is ensuring that the routes to each LAN subnet are added/removed as the VPN fails over. This requires monitoring of remote IP's and works pretty well using BFD however that isn't supported on SMB's. The other thought was to use Route-Based VPN's however it doesn't appear possible to have multiple VTI's to a single device due to the requirement to use the peer name in the config (i.e. the peer name would be the same for all three interfaces which again, isn't supported).
There's the added complication that we ONLY want VPN traffic to failover and not ALL traffic using the default route as that will saturate the microwave links.
I guess there is the option to use OSPF/BGP although I'm not certain how well that plays with domain-based VPN's.
The additional issue is the requirement to manage the SMB's over the internet and if the internet links go down (eth0), switch over to manage the device over the microwave links which would then of course be trying to manage the device over an IP not defined as the "Main address". This is less of an issue and we can live without this however it would be nice to ensure constant management of the devices.
Is what we're trying to achieve outside the realms of what the Check Point's can do?