Redundant IPSec and routing - I need some workaround

[sw2090]

I have this constellation:

FGT A (Shopsite) has static WAN IPs 

FGT B (on events) has dynamic WAN IP(s) and is not allways online

Between FGT A and B is two IPSec Tunnels which should provide redundancy.

Due to reasons (to me this is still bugs in FortiOS even if TAC still refuses to aknowledge them) the only way is to use Dial Up tunnels. That is because on S2S every side needs to know the opposite remote gateway. FortiOS does support the use of DDNS/FQDN as remote gw but without p1 autonegotation or oif the ipsec is in listening Mode on FGT A it does not update the gateway ip. So S2S will go down upon first ip change and not come up again.

To workaround this I use dial up because that always is in listenig mode in FGT A and it does not need to know the remote gw.

To achieve redundancy I use sdwan vpn. However with dial up tunnels on FGT A the sdwan fails to select the correct member  and route once the link status of the ipsec changes. This seems to be due to the fact that dial up tunnels get enumerated because they support concurrent tunnels.

So to still achieve automagic redundancy on that pair of ipsecs I need a way to adverize or announce the corrent route(s) once one ipsec comes up. Probably with some metric to not run into troubles if both are up ;)

I thought of BGP or similar but the examples I yet found on the net were too complex.

Does anyone have any advice what is best practice to achieve this?

[saneeshpv_FTNT · Accepted solution]

Hi,

Few pointers here,

1.) Add-route should be disabled on FGTA under IPsec Configuration to avoid adding of routes during dynamic IPsec negotiation

https://docs.fortinet.com/document/fortigate/6.4.5/administration-guide/534155/dynamic-ipsec-route-c...
2.) Mode-cfg to be disabled on FGTA and FGTB and number the tunnel interface on each FGT's with an IP of /29 subnet mask.

https://community.fortinet.com/t5/FortiGate/Technical-Tip-set-net-device-new-route-based-IPsec-logic... 

3.) set net-device disable - Dedicated interface not created on Hub for each dialup client and instead a Shared interface used for each dialup client and uses next-hop tunnel index for encrypting the payload.

4.) set tunnel-search nexthop - Configure under VPN Phase1 and to be used when IPsec routes are learned from a dynamic routing protocol

5.) set exchange-interface-ip enable - Enabled on both FGT's to allow the exchange of IPsec interface IP addresses. This allows a point to multipoint connection to the hub FortiGate.

6.) Run BGP or OSPF across IPsec Tunnels to advertise the required routes across the tunnel using Local Preference (BGP) or Cost (OSPF) as a metric to select the desired path. 
https://community.fortinet.com/t5/FortiGate/Technical-Tip-Controlling-OSPF-routes-in-case-of-paralle...

7.) SDWAN Rule to give preference to Tunnel1 over Tunnel 2 - So if tunnel1 goes down or routes are not available via tunnel1, FGT will select the tunnel2 provided it has a valid route.

Regards,

[sw2090]

the document you mention after 2. (or is that in 2.) says set net-device and set tunnel-search are removed in 7.0. set net-device still existes on a FGT60E running 7.0.12 here but set tunnel-search doesn't.

[saneeshpv_FTNT]

Hi,

Thanks for pointing out that, you can ignore that statement as there is slight change in the behavior in 7.0 onwards.

https://community.fortinet.com/t5/FortiGate/Technical-Tip-IPSEC-VPN-route-shows-a-different-gateway-... 

Let me know if you have any further questions.

Best Regards,

[sw2090]

after some testing:

I've two IPSec Tunnels on a 60E yanked to wan1 and wan2.  On the 60E this is a SDWAN-Zone (that even does not atm have any sdwan rule). Both terminate on the 300E here at HQ.

So to stay in my scheme the 300E would equal to FGT A and the 60E to FGT B.

add route is disabled on the 300E IPSec Tunnel (atm both tunnels terminate on the same ipsec on the 300E hence there is only one wan line available here). net-device is disabled on both FGT on all three IPSecs.

The 60E has a route to a subnet at HQ with the sdwan zone as interface and the HQ FGT300E as gw. Also I set a prio to the sd-wan zone members in the vpn zone.

The 300E has no sdwan vpn for this. It has redundant static routing for the subnet behind the 60E with prios set.

Both FGT have the required policies.

If I plug the wan1 (VPN 1 is yanked to that) to the internet on the 60E the first tunnel comes up and I can see a vaild route to our subnet for vpn traffic from the 60E on the 300E. I can ping and https the 60E from my pc at HQ office. Fine so far.

Now I unplugged wan1 again and waited for DPD to detect that tunnel down and once that happened I plugged wan2 in. Now the 2nd IPSec on the 60E came up and again I see a vaild route on the 300E and I can ping and https to the 60E again. 

So this is now working as it is supposed to. Will give it some more testing though.

So far many thx for your pointers as they led me to the right path :)