SD-WAN and AD-VPN - cannot add tunnel interfaces on the Hub fortigate 200E in 5.6.2

JPMfg · ‎12-01-2017

We are setting up a PoC here with two Fortigate 200E running 5.6.2 as dual-homed Hubs with two Fortigate 61E and VM-Fortigates and Azure-Fortigates as spokes. WAN-Emulators simulate the MPLS cloud, Internet is the public Internet. (all running FortiOS 5.6.2)

All according to this guide: http://cookbook.fortinet.com/client-side-sd-wan-ipsec-vpn-deployment-example-expert/

I have quickly done a working Dual-Cloud fully meshed AD-VPN setup (Internet+MPLS) with BGP (each connect with two tunnels to both Hub fortigates, one pair for Internet-connected sites, one pair for MPLS).

The central Fortigates have two AD-VPN tunnel interfaces, one for Internet (wan1) and one for MPLS (wan2).

So far so good.

But now i want to add SD-WAN interface to the two AD-VPN tunnel interfaces which works fine on the Spokes, but not on the Hub fortigates.

The FortiGate 200E do not allow me to set the Tunnel interfaces as members of a SD-WAN! Error message is:

hub1 # conf system virtual-wan-link

hub1 (virtual-wan-link) # set status enable

hub1 (virtual-wan-link) # config members

hub1 (members) # edit 1

new entry '1' added

hub1 (1) # set interface ADVPN-I

entry not found in datasource

value parse error before 'ADVPN-I'

Command fail. Return code -3

("ADVPN-I" is the name of the internet facing AD-VPN tunnel interface).

Anyone know why i cant set up SD-WAN on the hub systems? or is it only supposed to work on spokes?

JPM

mnantel_FTNT · ‎12-01-2017

Hi Juergen,

I'm not sure if this will make sense, but essentially because of the nature of the hub's IPSec tunnels which are of type "dynamic", those are templates and child instances of the template are created for each new connection. Therefore the SDWAN abstraction layer isnt as simple to apply at this level. I'll try to confirm with R&D - I havent personally tested this scenario as its relatively recent.

However given the use case here which you referred to (the cookbook article), if you read it closely you will notice that it implements SDWAN at the branch level, where we have static tunnels. In principle, the branch should indeed be the place where you implement these policies. Traffic initiated by the branch will return through the path it came from I would assume here, given equal cost paths at the hub. Thus the branch controls branch-initiated session paths. Do you have a considerable volume of hub-initiated traffic in your model?

--

Mathieu Nantel

Principal Presales Security Expert

-- Mathieu Nantel Systems Engineer / Conseiller Technique - Fortinet Montreal, QC

JPMfg · ‎12-05-2017

Hello,

I can understand if the dynamic nature of hub tunnels may interfere with SD-WAN feature making them mutually exclusive.

In order to setup SD-WAN rules for the few business critical application sessions that go from the central site to certain spoke sites.

I chose to split the Hub firewall into three VDOMs, connecting the ADVPN tunnels to VDOM-Interlinks and applying SD-WAN rules on the VDOM-Interlinks. This allows me to define VDI links as SD-WAN members.

I have one VDOM for Internet and one for MPLS, each terminating the AD-VPN cloud respectively, with VDOM-interlinks connecting them with each-other and with the root VDOM that performs SD-WAN on the VDOM-Interlinks (the uplinks).

This works for the PoC-Setup and may need to be re-evaluated for the final solution (if application sessions in that direction really need the SD-WAN functionality on central hub).

On the other hand, this is a feature of other SD-WAN solutions, so it would be nice to make these two features compatible in the future.

JPM