FortiGate SDWAN – Out of the Lab
I was recently involved in a project to roll out FortiGate SDWAN on what sounded like an almost text book scenario: two Hubs and two Branches. Obviously, I won’t post the client’s configs in this post but I will attach some configs from a lab that I created to generate configurations and test generally. (Please review with caution. I did a lot of tweaking and messing around in the labs and honestly can’t remember how I left them as it’s taken me a while to get round to blogging). It helped that I was able to get evaulation licences for four FortiGates and a Fortimanager as otherwise I’d have struggled. (The licences on these expired so I can’t review or test in situ anymore).
Fortinet have tightened up getting access to evaluation licences and it’s hard to a get a fully working one if you’re not working at a reseller/partner. Personally, I think this is a retrograde step: Cisco and Microsoft, not known for their charity, give you long evaluation periods of their products.
Here are my observations of the process generally:
Challenge One – It’s wasn’t greenfield!
I wasn’t dealing with new firewalls but production ones with many VPNs (and also BGP) already defined on them and a lot of important traffic already going through them. The way standard guides on deploying Fortinet SDWAN suggest deploying it is to define your hub and spokes, pump in the all the numbers, then hit go:
Now, I’m cautious creature and if I had had an attached Fortimanager at this site (which I didn’t) I would have hesitated to push huge chunks of VPN, BGP and SDWAN config to production firewalls.
Challenge Two – it’s not all about you
The client on this occasion was combining a datacentre move, storage upgrade and generally doing a lot more than put in SDWAN. Thus you may, like me, be working around a lot of other groups, projects and processes.
Challenge Three – you may have a moving target
Given the above, you may not have a stable environment as resilient circuits and branches are commissioned at different times meaning you have to put SDWAN elements in piecemeal – well, underlays or maybe one branch goes live first so the big bang approach above doesn’t work.
My Approach
OK – I’ll pause here to explain the approach I took which I freely concede is not immediately scalable: I took the Hub and Branch configs from my lab and after having tested connectivity, adapted the necessary code and pasted it to the relevant Fortis. Herein, I had a few problems: order of operations is relevant – you can’t paste in VPN tunnels before you create the phase1 and phase2 config. Also, you can’t add interfaces to an SDWAN zone if they are referenced elsewhere in the FortiGate configuration – mainly firewall policies – you can get away with routes and VPN references. (Presumably, I would have encountered such errors if I had used the Fortimanager to push the config) . Also, at one site, BGP was already in place doing resilient Internet routing between two links on one Hub – so the SDWAN’s BGP configuration had to incorporate this.
Attached are the Forti configs saved from my GNS3 environment. H1 and H2 are hubs and B1 and B2 are branches. These should work if you sort the routing between them and change the phase1 psks as I’ve obfuscated them even though they’re encrypted and were only ‘cisco123’ anyway!
(The files need renaming from *.txt to *.conf)