Forti SD-WAN DIA (and GNS3 Cloud types!)

I’ve been looking at SD-WAN recently and labbed up a simple implementation to test this using GNS3. This is the setup:

The southern cloud to the left allows management access to the Fortigate and the cloud next to it is a connection to a VMWare Workstation Linux box. The clouds north of the Fortigate are both GNS3 Nat clouds out to the Internet. It occurs to me this lab uses three different types of GNS3 cloud so let’s embrace that and dig further (These posts as much aide memoires to myself as anything else if/when I try to set up something similar). If you’re not interested and want to cut to the chase scroll down to SD-WAN.

The Mgmt1 cloud allowing access from the physical laptop which is running GNS3 and VM Workstation was added, unsurprisingly, on the local machine (when you add a cloud in GNS3 you chose whether to add it on the local machine or the GNS VM)

Of the laptop’s interfaces I’m using Ethernet8

This is in fact a (Microsoft KM-TEST Loopback Adapter) which is bridged to VMWare (see below) using VMnet0

VMnet0 is one of the interfaces on the GNS3 VM.

The cloud marked VMWARE was added on the GNS3 Virtual Machine itself:

And the eth3 interface on GNS3 virtual machine in VMware is a LAN segment

And finally the GNS3 nat clouds:

You don’t get to configure these and they just worked straight away (when something does that I generally don’t ask too many questions!). However, the router picked up addresses on the 192.168.124.0/24 subnet using DHCP which is my VMNet8 adapator:

This is defined as a NAT adaptor in VMWare Workstation:

SD-WAN.

Where was I? Yes SD-WAN. We have a simple LAN and two connections out to the Internet and will use SD-WAN policy to determine which one is taken. This is the logical topology:

The main components of Fortigate’s SD-WAN are SD-WAN Zones, SD-WAN Rules and Peformance SLAs. So addressing the first part of this we define an SD-WAN Zone composed of our two Internet interfaces:

We can then use this Zone to define our default route out to the Internet:
(Incidentally, when I first added SD-WAN members I thought they had to have static gateway ip addresses but if you change your interface to use DHCP then you’re offered the option of a dynamic gatway so the routers in the above diagram are superfluous: I could have removed them and got DHCP addresses direct on the firewall. On an early lab, I was having issues with Fortimanager getting DHCP so had got used to sticking a router in the mix.)

And so we have to define SD-WAN rules and Peformance SLAs that will be used in these rules.

The performance SLA I have chosen is doing DNS queries to Google with the described SLA targets:

The Rule which uses this matches all traffic:

…and is based on a Best Quality strategy measures against the Google_DNS SLA:

The SD-WAN widget on the Dashboards shows the health and traffic preferences of both interfaces.

…but essentially this is just providing a resilient connection to the Internet but leaving one interfaace unused so let’s try and be more ambitious and send a particular type of traffic out of one interface. We could used protocol, source or destination (this is essentially a form of Policy Routing) to select this traffic but I’ll tell traffic to www.labtinker.net to prefer port4 and keep everything else using the same preference for port3.

The interface members are displayed in the SD-WAN Rules GUI section together with the preferred interface (shown by the tick) and the hit count.

So browsing out from the Linux VM to www.labtinker.net and a series of other websites I see the following in the logs…

I’ve glossed over a few apsects of the configuration to give a general overview of using SD-WAN to steer traffic out of two Internet pipes. A more compelling use case is possibly using SD-WAN to replace a traditional WAN between sites using multiple links and ADVPN which I intend to try next.