WAN Failover Best Practice - New Failover Connection

[kknuckles]

I have a FG200D and we are getting ready to receive a new Cradlepoint 3G/4G router for failover of the main office only. The plan is to connect it to WAN2. My question is this: Would it be better to use WAN LLB and set a sky high priority like 99 for WAN1 and 1 for WAN2, or would it be better to use two static routes and weight them accordingly?

I mainly want to make sure WAN2 isn't going to be used unless WAN1 is absolutely down. I don't mind a small amount of traffic for health check but we are only allotted so much data per month on the fail over service without overage charges.

I've seen multiple posts about this and read multiple articles, but couldn't really determine the best method from those. I've only known FortiOS 5.4, which apparently isn't the favorite for this setup since most of the failover documentation still references 5.2.

Opinions and thoughts welcomed and thanks in advance.

Kevin

[neonbit · Accepted solution]

The default deep peer detection for the IPSEC tunnels is to send a packet every 20 seconds, and if 3 of them fail then it will deem it dead, ie your IPSEC will stay up for 60 seconds. You can change the dpd parameters (via cli) if you want it to fail over faster. The below config will make it fail over in 9 seconds

config vpn ipsec phase1-interface

edit <vpn name>

set dpd-retrycount 3

set dpd-retryinterval 3

end

[btp · Accepted solution]

Sure - but why not use the policy route approach that lies in the SDWAN logic?

[btp · Accepted solution]

Sure - «SD-WAN» in Fortinet World is an acronym for path selection. Not really SD-WAN, imho..

[MikePruett]

I, personally, would do this.

create a zone titled OUTSIDE

place primary internet provider and secondary internet provider in there.

Create two default routes, one to the primary and one to the secondary. Make the secondary have a slightly higher "priority" which in FortiOS just means cost.

Configure link health monitoring through CLI for each connection. If primary WAN fails the configured number of times then it will yank the route and use the backup line.

below is how to configure the link monitor

config system link-monitor

edit "wan1fail"

set srcintf "wan1"

set server "8.8.8.8"

set interval 3

set failtime 10

set recoverytime 10

set update-cascade-interface disable

set protocol ping

next

end

[kknuckles]

Thanks Mike!

[btp]

Even though this post is somewhat old - I have encountered something strange (running 5.4.5). When the link-monitor dies, the default route is withdrawn and the backup def.route is being used. However, the route for IPSEC is stuck for approx 80 seconds after the break:

(vdom) # get router info rout database

normal state S  *> 0.0.0.0/0 [5/0] is directly connected, IPSEC    *> [5/0] via 192.168.152.168, Internett, [5/0]     > [5/0] is directly connected, IPSEC-backup inactive, [5/0]    *> [5/0] via 192.168.152.170, wan2, [10/0]

link breaks S  [style="background-color: #ffff00;"]*> 0.0.0.0/0 [5/0] is directly connected, IPSEC[/style]     > [5/0] via 192.168.152.168, Internett inactive, [5/0]     > [5/0] is directly connected, IPSEC-backup inactive, [5/0]    *> [5/0] via 192.168.152.170, wan2, [10/0]

>80 secs later S   > 0.0.0.0/0 [5/0] is directly connected, IPSEC inactive     > [5/0] via 192.168.152.168, Internett inactive, [5/0]    *> [5/0] is directly connected, IPSEC-backup, [5/0]    *> [5/0] via 192.168.152.170, wan2, [10/0]

Someone got an idea on what's going on here?

[tanr]

How are your link monitors configured?

[btp]

My link-monitor is configured to withdraw the main default gw, in case of a L2 issue between CPE and PE. The secondary link should only be used whenever primary is down.

config system link-monitor     edit "PRIMARY"         set srcintf "Internett"         set server "192.168.185.1"         set gateway-ip 192.168.152.168     next end

The link-monitor goes into "die" mode as expected, and the default route is withdrawn. So it seems like a keep-alive-thing for the IPSEC tunnel that is screwing this up.

[neonbit · Accepted solution]

The default deep peer detection for the IPSEC tunnels is to send a packet every 20 seconds, and if 3 of them fail then it will deem it dead, ie your IPSEC will stay up for 60 seconds. You can change the dpd parameters (via cli) if you want it to fail over faster. The below config will make it fail over in 9 seconds

config vpn ipsec phase1-interface

edit <vpn name>

set dpd-retrycount 3

set dpd-retryinterval 3

end

[tanr]

@MikePruett,   I've seen a number of examples with the link-monitor field update-cascade-interface disabled, and some with it enabled.  I'm curious about why people are enabling/disabling it for different scenarios, instead of just using update-static-route.

From the CLI documentation:

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.

update-static-route {disable | enable}

Enable to remove static routes from the routing table that use this interface if the link monitor fails. Default is enable.

Thanks.

[MikePruett]

I just tell mine to pull the static route

[RBotha]

Thank you for the information.

(Ironically enough, our primary wan is dead at this moment.)

I've done this on our fortigate and I still encounter a problem. 

I have 2 static routes, wan1 is the failover, with priority 1. wan2 is the primary, with priority 0.

For our purposes, I've set update-static-route enable, update-cascade-route disable as I would like the physical interface to remain UP.

When the above kicks in, I lose all connectivity, and have to manually update wan2's static route priority to 2 (so that wan1 [the failover]'s static route priority is better than wan2's) for connectivity to be restored. This happens when I follow this link: https://kb.fortinet.com/kb/documentLink.do?externalID=FD36151 which essentially describes the same. 

I would like my static route priorities to remain as they were, and the link-monitor to dynamically "pull" the down-ed wan route, and re-enable said route when it comes back online.