Helpful ReplyHot!WAN Failover Best Practice - New Failover Connection

Author
kknuckles
New Member
  • Total Posts : 7
  • Scores: 0
  • Reward points: 0
  • Joined: 2016/02/29 15:56:02
  • Location: Pearl, MS
  • Status: offline
2017/03/20 12:47:51 (permalink) 5.4
0

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
#1
MikePruett
Platinum Member
  • Total Posts : 672
  • Scores: 13
  • Reward points: 0
  • Joined: 2014/01/08 19:39:40
  • Location: Montgomery, Al
  • Status: offline
Re: WAN Failover Best Practice - New Failover Connection 2017/03/20 13:14:01 (permalink)
0
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
#2
kknuckles
New Member
  • Total Posts : 7
  • Scores: 0
  • Reward points: 0
  • Joined: 2016/02/29 15:56:02
  • Location: Pearl, MS
  • Status: offline
Re: WAN Failover Best Practice - New Failover Connection 2017/03/20 14:02:49 (permalink)
0
Thanks Mike!
#3
phowardmhm
New Member
  • Total Posts : 8
  • Scores: 0
  • Reward points: 0
  • Joined: 2015/01/19 13:10:11
  • Status: offline
Re: WAN Failover Best Practice - New Failover Connection 2017/05/01 16:20:52 (permalink)
0
I will be doing the same setup as described, any thoughts or ideas are appreciated.  Thanks,

Pat
#4
wcbenyip
Gold Member
  • Total Posts : 394
  • Scores: 4
  • Reward points: 0
  • Joined: 2004/12/27 23:02:51
  • Location: HKSARG
  • Status: offline
Re: WAN Failover Best Practice - New Failover Connection 2017/05/01 21:00:21 (permalink)
0
Sounds this is a good method for WAN load balancing... but another trouble point is, you have to configure 2 complete set of policies for each interface going thru WAN1 and WAN2. That means, once you need to modify any policy from one of your huge no. of policies, you have to do it twice... and whenever need to create a new policy, you have to duplicate it for 2 WAN port.
 
I set the WAN LB with this same method, it's really painful. Just thought does there another way to make it more precise or simple? Double no. of policies and making a complex policy screen are really not a best practice.... and it's not the normal WAN LOAD BALANCING in the market...

Protect yourself~ http://www.secunia.com
MBCS CEH FCNSA
#5
Maxim Vanichkin
New Member
  • Total Posts : 18
  • Scores: 0
  • Reward points: 0
  • Joined: 2015/11/05 07:59:48
  • Status: offline
Re: WAN Failover Best Practice - New Failover Connection 2017/05/01 21:13:56 (permalink)
0
For exemple, ZyWALLs have "trunks" - 2,3,4... interfaces there (active, passive) - very easy! In your policies and routes you use only configured trunks - very convinent. Do FGs have such functionality?
#6
fl0at0xff
Bronze Member
  • Total Posts : 29
  • Scores: 0
  • Reward points: 0
  • Joined: 2016/08/23 00:13:56
  • Status: offline
Re: WAN Failover Best Practice - New Failover Connection 2017/05/01 21:41:30 (permalink)
0
Hello,
 
i'm not expert of DUAL wan but if I understand correctly, you simply want to do a WAN Failover and not a Load balancing right ? If yes, I suggest you to use only static. Here my guide lines:
  1. Configure default static route (wan1/wan2 with same distance but wan1 with lowest priority)
  2. Create link-monitor using CLI for each WAN. (config sys link-monitor) (-> set update-static-route disable)
  3. If you use IPSec, create your second IPSec that will use wan2. In CLI, don't forget to set the parameter "set monitor <gw_ip_wan1> that tell that this backup VPN IPSec must monitor the first one
  4. Add static route for your new IPsec (IPsec tunnel 2 with same distance than primary but higher priority)
  5. If you have not created a ZONE for WAN1 et WAN2, you must dupplicate all your policies/VIP for wan2
  6. If you have SSL/VPN, don't forget to add wan2 on listening interface for SSL/VPN configuration
  7. In case of IPsec, don't forget to configure the remote peer too.
 
You can test your link monitor using the command diagnose sys link-monitor status all
 
Hope this will help you.
 
BR 
 
#7
btp
Bronze Member
  • Total Posts : 25
  • Scores: 1
  • Reward points: 0
  • Joined: 2007/09/26 02:02:57
  • Status: offline
Re: WAN Failover Best Practice - New Failover Connection 2017/10/06 13:33:56 (permalink)
0
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
*> 0.0.0.0/0 [5/0] is directly connected, IPSEC
    > [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?
#8
tanr
Gold Member
  • Total Posts : 345
  • Scores: 12
  • Reward points: 0
  • Joined: 2016/05/09 17:09:43
  • Status: offline
Re: WAN Failover Best Practice - New Failover Connection 2017/10/06 14:20:03 (permalink)
0
How are your link monitors configured?
#9
btp
Bronze Member
  • Total Posts : 25
  • Scores: 1
  • Reward points: 0
  • Joined: 2007/09/26 02:02:57
  • Status: offline
Re: WAN Failover Best Practice - New Failover Connection 2017/10/07 09:07:48 (permalink)
0
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.
 
#10
neonbit
Gold Member
  • Total Posts : 381
  • Scores: 26
  • Reward points: 0
  • Joined: 2013/07/02 21:39:52
  • Location: Dark side of the moon
  • Status: offline
Re: WAN Failover Best Practice - New Failover Connection 2017/10/08 05:06:15 (permalink) ☄ Helpfulby tanr 2017/10/09 07:34:35
0
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
#11
tanr
Gold Member
  • Total Posts : 345
  • Scores: 12
  • Reward points: 0
  • Joined: 2016/05/09 17:09:43
  • Status: offline
Re: WAN Failover Best Practice - New Failover Connection 2017/10/09 08:17:20 (permalink)
0
@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.
#12
MikePruett
Platinum Member
  • Total Posts : 672
  • Scores: 13
  • Reward points: 0
  • Joined: 2014/01/08 19:39:40
  • Location: Montgomery, Al
  • Status: offline
Re: WAN Failover Best Practice - New Failover Connection 2017/10/09 11:29:44 (permalink)
0
I just tell mine to pull the static route

Mike Pruett
Fortinet GURU
#13
Jump to:
© 2017 APG vNext Commercial Version 5.5