Tunnel Failover Question

[BWiebe]

We have a client in a serverless location with a site-to-site tunnel to a 3rd party service provider which provides them access to their internal servers, DNS, etc.  The tunnel is linked directly to WAN1.

Their site has 2 ISP connections and we have internet failover configured using system link-monitor.  In general, with other clients where we control both sides of the connection, we setup failover tunnels linked to WAN2 and the site-to-site tunnels failover accordingly as well.

This works great, in general, however their service provider can't (or doesn't know) how to setup failover tunnels, and have configured their existing site-to-site tunnel as an 'alternate IP' for the tunnel (where we have it configured as a secondary tunnel linked to WAN2). 

As a result - they need us to have the failover tunnel interface in a 'disabled' state, unless it's specifically needed, in which case we enable the failover tunnel interface and disable the primary tunnel interface we have configured.  Once their primary ISP is back online, we need to reverse this.

Is there a better way we can manage this/more automated method we may have overlooked?  In general, we detect the ISP failure before the client, but there's times we don't and we'd like to see about automating this as much as we can.

Client is in the 5.6.* version of firmware (currently 5.6.3 and we plan to take them to 5.6.5).

Thanks!

[Toshi_Esumi]

We never used (needed) it but "set update-cascade-interface enable" might help if you set the "srcintf" as your tunnel interface. CLI manual says below:

update-cascade-interface {disable | enable}

Enable to bring down the source interface if the link health monitor fails. Disable to keep the interface up if the link health monitor fails. Default is enable.

[BWiebe]

I think the only issue with that setting is both interfaces need to be online at all times.  We can allow that with the WAN interfaces, but not the tunnel interfaces.

[Toshi_Esumi]

I misread your original post. You need to keep the backup side down when the primary is up. So that option wouldn't work. You might need to discuss with the provider to have a routing protocol like BGP between the client and them to have dynamic failover.

[BWiebe]

The problem, really, is the third party service here.  I had also asked if they could cope with a host name - and then we could have set the tunnel up to the host name - failover happens - hostname changes IP - everything is happy..... but their firewall apparently can't cope with a DNS name.....shrug.

[ede_pfau]

I seem to remember that there is an option which pulls the link down when the tunnel fails, via link fail detection or remote server detection. Can't pinpoint at the moment. This would be a great question to your FTNT SE.

[sw2090]

We do it this way here:

all locations have at least two WANs connected to the interned.

So we simply set up two ipsec tunnels from FOrtigate here top Fortigate there.

One is conneted to wan1 and the other to wan2.

Both have to have polices (since a tunnel won't come up at all without *g*).

Then I set up redundant static routes for the traffic over the tunnels which have different priorities (prio based routing). This will have both tunnels up and running all time but the traffic will primary go over the first one and only use the 2nd one when the 1st one is down...

What I Did not quite get is if your opposit site is annother ISP that has to provide you with a tunnel or if you have a fgt on both sides.

[BWiebe]

If it was a Fortinet on the other side I'd be happy :)

It's a Cisco or a Checkpoint (not sure which) and the third party has no idea how to setup failover properly on it, so they have the secondary ISP configured as an alternate IP for the tunnel on their end.

I've broached the topic of them getting the tunnel failover correct, but I doubt it will get anywhere.