Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
kknuckles
New Contributor

WAN Failover Best Practice - New Failover Connection

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

Thank you for your time,

 

Kevin W. Knuckles

Thank you for your time, Kevin W. Knuckles
4 Solutions
neonbit
Valued Contributor

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

View solution in original post

btp

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

-- Bjørn Tore

View solution in original post

-- Bjørn Tore
btp

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

-- Bjørn Tore

View solution in original post

-- Bjørn Tore
btp

That’s the main idea with Fortinet’s SD-WAN offering - path selection. We use this to use one of two fibers - and mobile backup if the sh*t hits the fan.. for many spokes.

-- Bjørn Tore

View solution in original post

-- Bjørn Tore
36 REPLIES 36
MikePruett
Valued Contributor

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

Mike Pruett Fortinet GURU | Fortinet Training Videos
kknuckles

Thanks Mike!

Thank you for your time,

 

Kevin W. Knuckles

Thank you for your time, Kevin W. Knuckles
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?

-- Bjørn Tore

-- Bjørn Tore
tanr
Valued Contributor II

How are your link monitors configured?

btp
Contributor

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.

 

-- Bjørn Tore

-- Bjørn Tore
neonbit
Valued Contributor

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
Valued Contributor II

@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
Valued Contributor

I just tell mine to pull the static route

Mike Pruett Fortinet GURU | Fortinet Training Videos
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.

Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors