Point-to-Point and VPN failover question

[BWiebe]

Client has a branch office, direct-connected to their DataCentre over a Point-to-point link using Fortigate cluster on both ends.  Comes in on both sides to port6 on a small network.

Routing from branch office to datacentre and vice versa is done via port6 and works well.  

Branch office also has dual-wan configured using SDWAN.  There are also VPN tunnels in case of failure of the Point-to-point link.

The routing through port6 has a better distance than the vpn tunnels so this link is preferred.

Today - the only way a failover can happen is if the Point-to-point fails on both ends.

The branch office runs FortiOS 6.0.10 and the DataCentre is on 6.2.4.  I had thought about adding the Point-to-point port to SDWAN and the VPN, but as there are policies already - this doesn't appear to be doable unless I wipe out all of the policies and recreate them after the fact relating to the VPN and the Point-to-Point (not a small task).

The VPNs don't currently have IPs associated to them.

What would be the easiest way to automate this failover for them and have the Point-to-point and VPN validate availability?

Should I consider using link-monitor with port6 and the VPN checking the same remote IP?  Something else?

What would be your recommendation?

This seems to be a fairly straightforward thing to do, but I suspect there's a few ways to accomplish this.

Thanks!

[sw2090]

I do this by haven to VPN S2S IPSec Tunnels from HQ to Site.

They both have the same policy (except from src/dst interface of course) and both have  a static route for every subnet I need to access from each site. There is just different prio and distance.

Traffic then primarily uses the route with loweset prio/distance and if that way is gone (Tunnel down) it switches to the other one.

Works fine here. Thus there may be other ways to do that too.

[BWiebe]

sw2090 wrote:

I do this by haven to VPN S2S IPSec Tunnels from HQ to Site.

They both have the same policy (except from src/dst interface of course) and both have  a static route for every subnet I need to access from each site. There is just different prio and distance.

Traffic then primarily uses the route with loweset prio/distance and if that way is gone (Tunnel down) it switches to the other one.

Works fine here. Thus there may be other ways to do that too.

Thanks for the response, appreciated. this is how I do it when there's just VPNs in the mix.

The issue here is the Point-to-Point link, and also to an extent the fact that they are clustered.  Because they are clustered/going through a switch VLAN and the device is outside the VLAN - there's not an easy way to test that each side is accessible.  The only way a failure of the link occurs is if both sides are disconnected, this is easy to simulate - but in practice when we've had failures of this kind before (at a similar site one side failed) we have to fail the other side of the Point-to-point link manually to make it use the VPN.

The distance for the routes over the point-to-point are 5, and over the vpn(s) are 10 and higher, hence the dilemma (one side down, the other side still trying to use non-existent/discontinuous link).

I do wonder if I set the distances equal and priorities different so it prefers the point-to-point link if that makes any difference but I doubt it.

I can't see an easy way of doing this without having to rebuild 75% of the config and using SDWAN unless I'm missing something glaringly obvious (link-monitor?).

I've talked with TAC on this before and our SE and not gotten very far beyond "Yes it's doable......." I was sent links for using SDWAN, etc, but that seems to presuppose that this is already in place before the VPNs are.  I know under 6.2.* we can do LAN+VPN but only one site is at 6.2.*, and again - this would be essentially a rebuild.

Any other thoughts appreciated.