Wat is SD-WAN?

SD-WAN (Software-Defined Wide Area Network) met Fortinet’s FortiGate is een netwerkoplossing die bedrijven helpt om hun WAN-verbindingen efficiënter en veiliger te beheren. Fortinet, een toonaangevend bedrijf op het gebied van cybersecurity, biedt een SD-WAN-oplossing die geïntegreerd is in hun FortiGate-firewalls.

De belangrijkste aspecten van SD-WAN met FortiGate:

1. Geïntegreerde Beveiliging en Netwerkbeheer

Fortinet’s SD-WAN-oplossing is uniek omdat het netwerkbeheer en beveiliging combineert in één apparaat. De FortiGate-firewalls bieden geavanceerde beveiligingsfuncties, zoals firewalling, intrusion prevention, en antivirus, die naadloos samenwerken met SD-WAN-functionaliteit. Dit betekent dat je netwerk niet alleen efficiënt is, maar ook optimaal beveiligd.

2. Intelligente Verkeerssturing

SD-WAN met FortiGate maakt gebruik van geavanceerde verkeerssturing om applicaties en diensten te optimaliseren. Dit houdt in dat het netwerk automatisch kan kiezen welke verbinding (bijvoorbeeld MPLS, breedband, 4G/5G) het beste is voor een bepaalde applicatie op basis van netwerkprestaties en -voorwaarden. Dit zorgt voor betere prestaties van bedrijfskritische applicaties en een verbeterde gebruikerservaring.

3. Kostenbesparing

Door gebruik te maken van een SD-WAN-oplossing kunnen bedrijven kosten besparen door goedkopere internetverbindingen zoals breedband en 4G/5G te gebruiken in plaats van duurdere, traditionele MPLS-verbindingen. FortiGate SD-WAN maakt het mogelijk om deze verbindingen te combineren en te optimaliseren zonder concessies te doen aan prestaties of beveiliging.

4. Centrale Beheer en Orchestratie

Fortinet biedt met hun FortiManager en FortiAnalyzer centrale beheer- en analyseplatforms waarmee beheerders hun SD-WAN-netwerken vanuit één interface kunnen beheren. Dit omvat het configureren, monitoren en troubleshooten van het netwerk. Met FortiManager kun je eenvoudig beleid en configuraties uitrollen naar meerdere locaties, wat schaalbaarheid en consistentie vergroot.

5. Verbeterde Applicatieprestaties

De SD-WAN-oplossing van FortiGate ondersteunt dynamische verkeersoptimalisatie, waardoor de prestaties van applicaties worden verbeterd. Dit is vooral belangrijk voor toepassingen die gevoelig zijn voor vertraging, zoals videoconferenties en VoIP (Voice over IP). De oplossing kan verkeer prioriteren op basis van de applicatiebehoeften en de kwaliteit van de netwerkverbinding.

6. Veilige toegang tot Cloud en SaaS

Fortinet SD-WAN biedt veilige en betrouwbare toegang tot cloudgebaseerde toepassingen en SaaS (Software as a Service) diensten. Dit is essentieel voor moderne bedrijfsomgevingen waar steeds meer applicaties in de cloud draaien. De SD-WAN-oplossing zorgt ervoor dat het verkeer naar deze toepassingen efficiënt wordt geleid en goed beschermd is.

7. Schaalbaarheid

Fortinet SD-WAN is zeer schaalbaar en kan worden ingezet in zowel kleine bedrijven als grote, gedistribueerde ondernemingen. De oplossing groeit mee met de behoeften van het bedrijf, wat betekent dat het eenvoudig is om extra locaties of verbindingen toe te voegen zonder grote veranderingen in de infrastructuur.

Samenvatting: SD-WAN met FortiGate biedt een krachtige combinatie van netwerkbeheer en beveiliging, waarmee organisaties hun WAN-infrastructuur kunnen optimaliseren, kosten kunnen besparen, en de prestaties en veiligheid van hun applicaties kunnen verbeteren. Fortinet’s geïntegreerde aanpak zorgt voor een eenvoudig te beheren, flexibel en veilig netwerk dat is afgestemd op de eisen van moderne IT-omgevingen.

Hoewel er meerdere partijen zijn die implementatie van SDWAN ondersteunen gaan we in deze blog SDWAN met behulp van het product van Fortinet (Fortigate) uitdiepen.

SD-WAN implementatie high level

Kortom, genoeg redenen om aan de gang te gaan met de implementatie van SD-WAN. Maar hoe werkt dit nu precies?

In deze blog zullen we gaan toewerken naar onderstaande “high level design” in een minimalistische vorm (dus enkel voor HQ + één remote office). Conceptueel zal dat de blauwdruk zijn voor alle remote locaties. De ZTNA (of ook wel Zero trust network access) implementatie is in dit geval out-of-scope maar bied wel mooie voordelen in combinatie met SD-WAN en Azure/DC diensten.

Het idee is om afhankelijk van waar de applicaties / diensten van de organisatie draaien een SDWAN overlay te bouwen naar of: Azure of: je eigen Datacenters. In deze blog gaan we er vanuit dat er in het geval van Azure virtuele Fortigate VM’s draaien of in het Datacenter fysieke / virtuele Fortigates (/VM’s). Bij het voorbeeld in de blog gelden de volgende regels:

• De klant maakt op dit moment gebruik Fortigate firewalls en wilt de huidige WAN verbindingen vervangen voor goedkopere connecties (Internet lijnen, 4g/5g verbindingen of straalverbindingen).
• Het moet mogelijk zijn om tussen remote locaties via (ADVPN) rechtstreeks van office naar office te verbinden.
• Remote workers moeten zowel bij Azure als Datacenter resources kunnen komen via een veilige remote oplossing (ZTNA: Zero Trust Network Access, oftewel: de next gen VPN oplossing). De implementatie hiervan is out-of-scope van deze specifieke blog.
• Elke locatie heeft verkeer wat naar SaaS Cloud diensten gaat en deze moeten per office locatie lokaal over de internet verbinding uitbreken.
• HQ bied via BGP enkel de netwerk reeks 10.0.0.0/8 aan en de remote office locaties adverteren enkel de 192.168.X.Y reeksen.
• Elke locatie wordt redundant (via meerdere connecties ontsloten).
• Beide paden (IPSEC tunnels en internet lijnen) worden actief gebruikt voor het afhandelen van verkeer.
• Omdat de complexiteit in het SD-WAN stuk zit focussen we primair op de IPSEC tunnels + BGP + SD-WAN

SD-WAN implementatie low level

Als we naar die criteria kijken hanteren we in deze blog onderstaande netwerk design.

Startpunt

Beide locaties (HQ en Office1) hebben twee internet verbindingen en zijn online. De client reeksen erachter zijn geconfigureerd en de switches zijn ook online.

Configuratie: Local breakout Office 1 Fortigate

Omdat remote office 1 online is gekomen willen allereerst ervoor zorgen dat deze locatie redundant internet connectiviteit heeft via SD-WAN. Dit configureren we relatief gezien eenvoudig:

• Vanuit de Fortigate navigeer je naar network > SD-WAN > SD-WAN zones.
• Hier maken we een nieuwe SD-WAN zone aan: sdwan-internet
• In deze SDWAN zone voegen we twee interfaces toe: namelijk WAN1 en WAN2 (beide ISP links).
• Vervolgens navigeren we naar het menu Performance SLAs, hierin maken we een IPSLA aan met de naam IPSLA_Internet.
• Hier configureren we probe mode: Active, protocol: ping, en de servers: 8.8.8.8 en 1.1.1.1. Wederom voegen we bij participants WAN1 & WAN2 toe en stellen we failures before inactive in op 5 en restore link after 5 check(s) en zetten we een vinkje “enabled”, bij Actions when inactive: “update static route”.
• Deze IPSLA zorgt ervoor dat er periodiek pings worden verstuurd naar destination 8.8.8.8 en 1.1.1.1 over beide WAN links en op het moment dat er 5 checks falen zal de static route aangepast worden en zal verkeer niet meer over de “gefaalde” link verzonden worden maar enkel nog over de operationele link.

• Daarna maken we een nieuwe priority rule aan: pr-sdwan-internet-best-quality met de volgende settings: Source Address: 192.168.0.0/24, 192.168.1.0/24, Status enabled, destination Address: “All”, protocol number “Any”, Interface selection strategy: Best Quality, Interface preference zowel WAN1 als WAN2, zone preference “sdwan-internet” en als measured SLA: “IPSLA_Internet”, Quality criteria: “Latency”.
  • Hiermee geven we aan wanneer de SDWAN rule moet afgaan: oftewel, als verkeer vanuit 192.168.0.0/24 of 192.168.1.0/24 geïnitieerd wordt richting een destination op alle poorten via de interfaces WAN1 en WAN2 op de zone SDWAN-internet waarbij de SLA via de IPSLA_internet bepaald word en latency als criteria wordt gebruikt. Routeer dit verkeer dan via de lowest latency link naar het internet toe. Je kunt hier uiteraard ook andere criteria meegeven (afhankelijk van de behoeften van het type verkeer / de dienst).
• Als laatste stap navigeren we naar Network > Static routes en maken we hier een nieuwe static route aan met de volgende settings: destination: subnet, 0.0.0.0/0 interface sdwan-internet en status Enabled.
• Bouw daarna de gewenste firewall policies vanuit je source zone (waar je clients inzitten) richting de sdwan-internet zone.
• En hiermee hebben we de lokale internet breakout configuratie voor remote office 1 afgerond.
• Als de configuratie goed geimplementeerd is zul je nu in het SD-WAN overzicht zien wat de “stats” zijn van de betreffende links en welke link in de SDWAN config geprefereerd wordt.

Configuratie: IPSEC tunnel 1 & 2 Remote office 1

Vervolgens gaan we een IPSEC tunnel bouwen over de eerste ISP connectie in dit geval WAN1.

• Navigeer in het menu naar VPN > Ipsec tunnels en klik op “create new IPsec tunnel”
• Geef de tunnel een passende naam bijv: HQ_1, geef het remote IP address op waarop HQ “luistert” om een IPsec tunnel over op te zetten, bijvoorbeeld 203.0.113.2, selecteer de interface WAN1, de local gateway waarop de office locatie de tunnel moet gaan onderhandelen, NAT traversal enabled of uit (afhankelijk van het feit of de overkant achter NAT vertalingen zit ja of nee). In dit geval (omdat het een public ip is waar we naartoe verbinden) mag NAT traversal uit. Stel Auto discovery receiver in op “enabled” want voor ADVPN shortcuts is het vereist dat de office 1 firewall van HQ gaat leren waar de andere office locaties zich bevinden voor directe ADVPN tunnels tussen de locaties.
• Stel de preshared key in (identiek aan zowel HQ als de office 1 kant) en configureer de phase 2 selectors met alle locale addresses en remote addresses (twee keer het “all” object) zodat je op firewall basis kunt bepalen wat wel en niet over de tunnel mag.
• Stel onder phase 1 proposals local ID sd-wan-office-1 in.
• Klik daarna op create/OK en doe dit nogmaals voor IPSEC tunnel 2 met het public IP en de preshared key die van toepassing zijn voor die specifieke tunnel.

Configuratie: IPSEC tunnel 1 & 2 HQ

• Voer voor HQ dezelfde settings uit als voor remote office 1 behalve het public IP, en stel hier geen auto discovery receiver in op enabled maar “disabled” en stel auto discovery sender in op “enabled”. Dit omdat HQ de gegevens om tunnels tussen de office locaties op te zetten gaat delen met de office locaties.
• Configureer de remote gateway als dialup user met dezelfde preshared key als voor tunnel 1 van office 1
• En stel IKE2 + peer ID sd-wan-office-1 in.
• Herhaal deze stappen voor tunnel 2.

Configuratie: IPSEC tunnel 1 & 2 Remote office 1 – IP adres & overlay

Als er gebruik gemaakt wordt van hetzelfde public IP om de tunnels overheen op te bouwen dan heeft de fortigate extra settings nodig (via command line) om onderscheid te kunnen maken tussen de IPSEC tunnels.

Namelijk:

Config vpn ipsec phase1-interface

Edit [tunnel naam]

set network-overlay enable

set network-id 1 (of 2 voor tunnel 2)

Verder gaan we nu de ip gegevens configureren op de fysieke tunnel zelf zodat we BGP (omdat we active-active willen draaien over beide tunnel interfaces) kunnen configureren.

• Navigeer naar network > interfaces > en open hier onder physical interfaces de 1^e tunnel door deze te editten.
• Bij het veld “IP” gaan we het ip adres configureren voor de interconnect tussen de fortigate firewalls. In ons geval: 10.0.1.2 met als netmask 255.255.255.255. Het Remote IP / netmask wordt dan: 10.0.1.1 255.255.255.0 (HQ IP gegevens) want we willen mogelijk ook nog andere office locaties in dezelfde reeks koppelen in hetzelfde subnet om BGP over te configureren.
• Zet hierbij ook ping aan onder administrative access zodat we kunnen testen of de directe connectie te pingen is vanuit HQ.

Ditzelfde doen we ook voor tunnel 2 met de ip gegevens: 10.0.2.2, netmask 255.255.255.255 en het remote IP 10.0.2.1 255.255.255.0 en ping aan.

Configuratie: IPSEC tunnel 1 & 2 HQ – IP adres & overlay

De stappen voor de ipsec tunnels aan de kant van HQ zijn identiek aan die van de remote office behalve wederom het IP adres wat ingevuld word. Aan de HQ kant vullen we namelijk het volgende in voor tunnel 1: 10.0.1.1 met netmask 255.255.255.255 en het remote ip 10.0.1.2 255.255.255.0

En voor tunnel 2: 10.0.2.1 met netmask 255.255.255.255 en het remote ip 10.0.2.2 255.255.255.0.

Wederom voor beide ping aanzetten onder administrative access.

Configuratie: SDWAN zone HQ + office 1

• Vervolgens gaan we een nieuwe SDWAN zone aanmaken, op HQ noemen we deze zone sdwan-office en voegen we hier de twee ipsec tunnel interfaces aan toe.
• Aan de remote office 1 zijde noemen we deze sdwan-HQ en voegen we ook de twee IPsec tunnel interfaces toe.

Configuratie: SDWAN performance SLAs HQ + office 1

• Nu maken we een nieuwe IPSLA_Office aan (aan de HQ kant)
• En IPSLA_HQ (aan de office kant)
• Hier vullen we probe mode active in, protocol ping, participants specify tunnel 1 en tunnel 2 en update static route op enabled. Dit doen we wederom aan beide kanten. Bij servers vul je de gegevens in van de systemen die altijd online moeten zijn, bijvoorbeeld: subinterfaces die op de firewall aanwezig zijn die pingable zijn waarin de clients/systemen zitten achter de HQ / office firewall. Deze servers worden gebruikt om te bepalen of een link nog actief gebruikt mag worden om verkeer overheen te routeren of dat deze als “down” wordt gemarkeerd.

Configuratie: SDWAN priority rule HQ + office 1

• Creëer nu bij remote office 1 een SD-WAN rule met de naam pr-sdwan-hq-best-quality
• Met als source 192.168.0.0/24 en 192.168.1.0/24 en als destination de 10.0.0.0/8 (alles richting HQ), any protocol, best quality, interface tunnel 1 en tunnel 2, de zone preference sdwan-hq en de measured sla IPSLA_hq.

• Voer exact hetzelfde uit aan de HQ kant maar dan met source 10.0.0.0/8 en destination 192.168.0.0/24 en 192.168.1.0/24 en sdwan-office en IPSLA_office

Configuratie: firewall regels

Na het opbouwen van de SDWAN & tunnel configuratie is het tijd om firewall regels te implementeren.

• In dit voorbeeld maken we op de office locatie een permit any naar de HQ firewall via de SDWAN zone sdwan-HQ, al het filteren zal via firewall regels aan de HQ firewall uitgevoerd worden (dit om de office policy set zo eenvoudig mogelijk te houden).
• Wat hierbij wel belangrijk is is dat bij ADVPN tunnels tussen office locaties ook firewall regels nodig hebben in de firewalls van de betreffende office locaties (omdat dit verkeer niet via HQ zal verlopen maar direct).
• Zorg er dus voor dat er firewall regels zijn vanuit office > HQ en vanuit HQ naar interne systemen, maar ook vanuit HQ > office en in het geval van office > office ook regels tussen deze locaties op de firewalls die zich in de twee office locaties bevinden.

Configuratie: BGP

Nu de tunnels, de firewall regels, SDWAN en de firewall regels geïmplementeerd zijn is het tijd om de BGP configuratie klaar te zetten.

• Navigeer naar network > BGP.
• Configureer hier het local AS nummer bijvoorbeeld: 64952
• Specificeer hier je neighbors en hun remote AS op office locatie 1 bijvoorbeeld: 10.0.1.1 AS 64952 en neighbor 2 10.0.2.1 AS 64952.
• Activeer onder beide neighbors je interface en update source op je betreffende tunnel interface (1 voor neighbor ip 1 en tunnel 2 voor neighbor ip 2).
• Zet activate IPv4 aan vul het BGP password in en activeer capability: graceful restart (wat in het geval van een wegvallende neighbor ervoor zorgt dat de routes als “stale” entry’s nog even blijven bestaan en wat BGP de tijd geeft om na een failover opnieuw te negotiaten binnen de termijn dat graceful restart de packetten over de “stale” routes blijft forwarden zonder netwerk interruptie.
• Configureer de neighbor groups en neighbor ranges, namelijk sdwan-hq-1 en sdwan-hq-2 met neighbor ranges 10.0.1.0/24 en 10.0.2.0/24. Dit zorgt ervoor dat nieuwe neighbors met BGP negotiaten als ze in die reeksen vallen. Dus nieuwe locaties die met een IPsec tunnel ip van bijvoorbeeld 10.0.1.3 en 10.0.2.3 online komen zullen zodra de tunnels up zijn ook BGP gaan kletsen met de andere locaties.
• Zet IBGP multipath aan
• Configureer onder IP/Netmask de reeksen welke mee moeten doen in BGP / BGP uitwisseling. In ons geval: 10.0.1.0/24, 10.0.2.0/24, 192.168.0.0/24 en 192.168.1.0/24.
• En redistribute static ipv4 netwerken in BGP met een routemap (zodat je ook management IP’s in BGP kunt adverteren over de redundante ipsec tunnel).

• Voer dezelfde stappen uit aan de HQ kant met de volgende afwijkende settings:

• Navigeer naar network > BGP.
• Configureer hier het local AS nummer bijvoorbeeld: 64952
• Specificeer hier je neighbors en hun remote AS op HQ bijvoorbeeld: 10.0.1.2 AS 64952 en neighbor 2 10.0.2.2 AS 64952.
• Activeer onder beide neighbors je interface en update source op je betreffende tunnel interface (1 voor neighbor ip 1 en tunnel 2 voor neighbor ip 2).
• Zet activate IPv4 aan vul het BGP password in en activeer capability: graceful restart
• Configureer de neighbor groups en neighbor ranges, namelijk sdwan-office-1 en sdwan-office-2 met neighbor ranges 10.0.1.0/24 en 10.0.2.0/24. Dit zorgt ervoor dat nieuwe neighbors met BGP negotiaten als ze in die reeksen vallen. Dus nieuwe locaties die met een IPsec tunnel ip van bijvoorbeeld 10.0.1.3 en 10.0.2.3 online komen zullen zodra de tunnels up zijn ook BGP gaan kletsen met de andere locaties.
• Zet IBGP multipath aan
• Configureer onder IP/Netmask de reeksen welke mee moeten doen in BGP / BGP uitwisseling. In ons geval: 10.0.1.0/24, 10.0.2.0/24, en 10.0.0.0/8 (HQ client reeksen).

Validatie en optimalisatie

Eventueel heb je nog de mogelijkheid om met behulp van route-maps + prefix lists netwerken te filteren of als summary te adverteren waardoor de routing tables in de office locaties en HQ mooi “schoon” blijven. In ons voorbeeld is er namelijk enkel een summary op de office locaties nodig van 10.0.0.0/8 richting HQ. En meer specifieke routes van 192.168.X.Y richting de office locaties die deze reeksen adverteren. Dit kun je doen door een prefix-list te maken met de netwerk statements die toegestaan moeten worden en deze prefix-list in een route-map op te nemen welke in BGP IN / OUT word toegepast voordat BGP de netwerken in zijn routing table opneemt. (hier kun je online genoeg guides over vinden).

Na deze configuratie heb je een redundante locatie geconfigureerd met SDWAN en is het belangrijk om te valideren dat bij het offline trekken van 1 specifieke link op locatie (bijvoorbeeld ISP1) al het verkeer met maximaal 1 a 2 ping loss blijft forwarden. Test dit dus met beide ISP links! Want meten is weten en de theorie verschilt soms van de praktijk.

Conclusie

Ben je na het lezen geïnteresseerd geraakt in deze implementatie, heb je vragen of je wil vrijblijvend contact hebben? Neem dan vooral contact met ons op via https://ant-networks.com/contact/