5.2 - Virtual WAN Link

[Chura]

Hi, Nice new feature that allow you to gather 2 WAN links to single virtual load balanced. I wonder, its applied to VPN too ? I have 2 VPN to same location, wonder if I can bind them to get my policy neat. I don' t have lab device available for 5.2 testing :\

[veechee]

How is a Virtual WAN link different than putting WAN interfaces into a zone? That is what I do now. I suppose if it was used for grouping VPNs that would be a difference, but I don' t think so because VPNs have to account for specific public IP addresses.

[Dipen]

How is Virtual WAN Link different from earlier Weighted Load balancing under Router>>settings Is mechanism the same?

[Chura]

Same for WAN interface, each one hold different IP. The virtual WAN allow you to load balance and more.

[Michael_Ledet]

Can't find any documentation specifying whether this works with IPSEC and SSL VPN.  Anyone test this?

[emnoc]

You won't find any documentation since the virtual-link is  ECMP load-balance outbound traffic. The  virtual-wan interface is also not selectable for a 1> ipsec  termination 2> ssl-vpn termination 

Look in the  fortinet 5x beta  forum and will find numerous  posting about this.

[Fahad]

it would be very helpful if it can support IPSEC as you can failover based on latency

[emnoc]

Don't see how that would work plus the fact the virtual-wan-load interface is either src or WRR based. Than the peer would need 2  static vpn settings for both of your wan1 and wan2. If you need IPSEC vpn failover, build a 2nd vpn and use a tunnel monitor, define the 2nd tunnel to the 2nd WAN2 (2nd ISP uplink )

This feature is already in place btw.

[emnoc]

Don't see how that would work plus the fact the virtual-wan-load interface is either src or WRR based. Than the peer would need 2  static vpn settings for both of your wan1 and wan2. If you need IPSEC vpn failover, build a 2nd vpn and use a tunnel monitor, define the 2nd tunnel to the 2nd WAN2 (2nd ISP uplink )

This feature is already in place btw.

[Michael_Ledet]

That's what I figured.  Being able to reduce duplication of policies across multiple wan interfaces is a nice side effect.  But considering that you must remove the wan interfaces policies prior to moving to the functionality is a bummer.  Would be nice if there was some type of transition where when moving this Virtual WAN Link have it take the policies from a WAN interface as the starting point in some automated fashion.  The other gotcha I see with this is that once you go down this path won't you need to revert back to the non Virtual WAN Link implementation to support it on the existing wan interface(s)?