Failover IPSEC tunnel policy based

[FortiGay]

I know this is officially unsupported, but still I am curious if someone somehow has a clever solution :)

The problem description:

On our central datacenter firewall (Fortigate) we have multiple tunnels towards customers who have overlapping destination subnets so policy-based tunneling is a must. A new customer has two tunnels which need to be in a failover setup. Therefore I have two identical policies, both pointing to a different IPSEC tunnel. All traffic for this customer now matches always on the first policy, resulting in the backup-tunnel-policy below it to be never hit.

I already thought of an automation-stitch with a script to disable a policy on an event (monitoring the primary WAN IP of the customer) but I think that is too much hassle or might have unexpected results.

In the past, when using Cisco ASA, policy-based tunnels could be easely configured as a backup (just add a second peer IP address on the crypto-map). Fortigate lacks this mechanism.

Of course there can be a setup by NATting the customers' subnet to make it unique and then rebuild to route-based tunnels with different static route distances, but before I go that way I would like to know if there is a clever solution I haven't thought of yet :)

Thanks,

Mike

[ezhupa]

Hello Mike,

You need the second tunnel to act only as a back-up or also to handle maybe part of the traffic?
SDWAN would be a solution, if that's possible for you but would mean redoing the config since it will require deleting the original policies and creating new ones with destination SDWAN zone and after that manipulating the traffic through SDWAN rules. 
SDWAN rules are similar to policy routes in concept, so should be the same logic but with more granular control.  (If you want both tunnels to be active for separate clients i.e client A uses tunnel A and client B uses tunnel B I don't think it can work unless maybe the source subnets are different?)

Another solution might be a link monitor on both the IPSEC interfaces monitoring 2 separate IPs.
If the monitor fails on the primary IPSEC, the FGT will remove the static route from the routing table, hence causing the PBR to not get triggered (since normally it would need an active route).
This way, then the other tunnel would be used. This case scenario is only if the other tunnel is intended as a backup tunnel to be used only when the primary is down. 

Also, the automation stitch is not a bad idea. 
If you want both of them to be used for separate clients, you can try to have 1 of  the customers with the subnet IPs natted as per the below article:
https://docs.fortinet.com/document/fortigate/7.6.0/administration-guide/426761/site-to-site-vpn-with...

The other destination subnet you can leave as is. Since the subnets for one client will be natted, it shouldn't overlap anymore. You can use a source filter on the VIP in the destination side FGT (where the subnets overlap) to make the VIP work only for the subnet of 1 of the customers.

Hope this can help!

[FortiGay]

Hi ezhupa,

Thanks for your input!

The backup tunnel is for redundancy only, so no shared traffic over both tunnels.

The fact is I only have the default-route over WAN1 and the traffic follows this route, matches the policy and then got encrypted through the tunnel. The customer side has two internet connections with two tunnels towards our Fortigate (two tunnels, same endpoint)

Since I have 1 default route I have no entry in the routing table to choose the correct tunnel (hence policy based tunneling, not policy based routing).

The NAT looks viable, but it will be make me redo the tunnel configuration from policy based to route based afterwards.

Thanks,

Mike