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

5.2 - Virtual WAN Link

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 :\

//Chura CCIE, NSE7, CCSE+

//Chura CCIE, NSE7, CCSE+
9 REPLIES 9
veechee
New Contributor

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
New Contributor III

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

Ahead of the Threat. FCNSA v5 / FCNSP v5

Fortigate 1000C / 1000D / 1500D

 

Ahead of the Threat. FCNSA v5 / FCNSP v5 Fortigate 1000C / 1000D / 1500D
Chura
New Contributor

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

//Chura CCIE, NSE7, CCSE+

//Chura CCIE, NSE7, CCSE+
Michael_Ledet
New Contributor

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

emnoc
Esteemed Contributor III

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.

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
Fahad
New Contributor III

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

FCSNP 5, JNCIS-FW,JNCIA-SSL ,MCSE, ITIL.

FCSNP 5, JNCIS-FW,JNCIA-SSL ,MCSE, ITIL.
emnoc
Esteemed Contributor III

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.

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
emnoc
Esteemed Contributor III

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.

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
Michael_Ledet
New Contributor

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)?

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