SD-WAN:

Con SECURE SD-WAN: connetti dei siti BRANCH, ma la questione è che un FG può disporre di diverse
opzioni di collegamento WAN; potrebbe essere collegato ad un CPE su un servizio MPLS, ad una CPE che
fornisce collegamento ad Internet, ad una LTE per un collegamento wireless, definirei queste
connettività/interfacce come UNDERLAY, che è un termine usato in ambito il SD- networking , più
l’effettiva topologia/connettività fisica e se c’è un UNDERLAY ci sarà anche un OVERLAY, che è una
topologia logica che si realizza utilizzando l’infrastruttura UNDERLAY, ad esempio un OVERLAY potrebbe
essere un tunnel IPsec verso un sito remoto, e come ben sappiamo l’ IPsec utilizza il meccanismo SPI per
definire l’indirizzamento, che è derivato dall’ UNDERLAY, e quindi appunto è un OVERLAY, quindi è
qualcosa di definito via software e protocollo. Quindi capiamo che il nostro FG in un sito BRANCH può
disporre di connettività multipla, sia essa UNDERLAY che OVERLAY, perciò l’idea che sta alla base dell’SD-
WAN, è un collegamento WAN definito e/o controllato via software. Tramite degli elementi che saranno
dei controller (applicazioni) che hanno l’obbligo di controllare l’utilizzo di una rete WAN. Ricordiamo che il
FGM per quanto riguarda SD-WAN, assolve ai ruoli classici di un controller SD-WAN. La programmabilità
della connettività WAN è demandata, o al singolo box e quindi in questo caso è distribuita, o è controllato
centralmente. Quindi la prima grande differenza è: La centralizzazione del control plan (che è la logica di
funzionamento, che è distribuibile su ogni singolo FG) è un opzione, non è obbligatorio il FGM (che è il
controller centrale con la funzionalità specifica per l’SD-WAN) , ma non è un elemento obbligatorio
neanche per una security fabric (per la security fabric è indispensabile il Fortianalyzer e no il FGM).Quindi
questa è una prima grande differenza; si vuole un controllo centralizzato per una facilità di gestione di una
intranet con tanti siti ma non è indispensabile l’ SD-WAN può essere gestita anche in maniera distribuita
ovvero programmando ogni sito BRANCH in maniera autonoma. Quindi il FG si sta spingendo verso una
domanda di utilizzo più intelligente e controllato di connettività WAN magari in sostituzione del servizio più
costoso quale è l’MPLS. FG punta sulla caratteristica della sicurezza, quindi del fatto che il controller SD-
WAN è integrato in Fortios, non è un componente aggiuntivo che può rallentare in S.O., dove nell’unica
base di codice contiene anche l’UTM e tutti i security profile, va da se che questa caratteristica SD-WAN,
garantisce anche l’integrazione con i security profile, e cioè NGFW, e quindi di non soffrire di quelle
problematiche di efficienza nell’utilizzo. Tra l’altro questa integrazione garantisce che un BRANCH è
totalmente sicuro, partendo dall’end-device che con un Forticlient o software di terze parti riconosciuto da
Fortinet che hanno implementato le API, dal FG si raggiunge la sicurezza anche a livello di SD-WAN a
prescindere da quale underlay viene impiegato. Una novità recente di Fortinet, è che il FG100F hanno porte
a 10 giga pronte per ospitare connettività superiore al gigabit e in più hanno il SOC specifico per SD-WAN.
Quindi tutte le regole SD-WAN, il riconoscimento delle applicazioni, viene direttamente accelerato a livello
di HW, a livello proprio di ASIC (Degno di nota l’investimento di Fortinet, in quanto, la versione “F” del
FWFG porta con se un chip che accelera a livello HW le potenzialità dell’SD-WAN). Quindi in sostanza
Fortinet è pronta per gestire la connettività multipla, in maniera fortemente controllata e orientata alle
applicazioni.
Che cos’è la Digital trasformation per i Marker?

Significa far notare alle potenziali aziende clienti di Fortinet, che esse non vanno più soltanto a generare
traffico verso l’HQ o sito centrale di una connettività intranet MPLS VPN. non è più solo questo, adesso c’è
tantissimo software SAAS, e stiamo parlando di cloud computing che dobbiamo intenderlo come 3
modalità di erogazione, prendo un server, prendo un virtual DC, esempio su AZURE, su AWS, su GOOGLE e
vado a reperire una infrastruttura IAAS service, e poi su questa infrastruttura server, rete, insomma vado a
caricare e gestire Io il sistema operativo, installare le applicazione, quindi ho l’infrastruttura come servizio e
poi su questa vado a caricare le app aziendali, faccio il Deployment. Poi avrò il PAAS che è una via di mezzo,
io non voglio curarmi direttamente del dimensionamento e delle risorse HW, io acquisto il middleware,
acquisto il DB, acquisto i software Development kit, acquisto le chiamate lamda, i servizi bot generici,
quindi vado ad acquistare componenti del mio prodotto, della mia applicazione, che però devo crearla io, e
quindi non sto prendendo direttamente in affitto software ma prendo in affitto componenti software, ed è
una piattaforma. SAAS io acquisto e pago per l’utilizzo di applicazioni funzionanti complete e quindi
software come servizio: Salesforce, Office365, Citrix e così via. Quindi stiamo parlando di diverse modalità
di accesso ai servizi cloud questa è la Digital Trasformation di cui si sente tanto parlare; ovvero in termini di
networking, non soltanto più accedere ad asset fisicam localiz in House, presso la nostra infrastrutture o un
unico DC dove risiedono aziendali, ma i dati sono un po’ sparsi, sono un po’ nel cloud pubblico, un po’ nel
cloud privato, un po’ in House; e questa Digital Trasformation del mondo Enterprise, guida
necessariamente l’adozione a soluzioni SD-WAN, perché alcuni di questi servizi non per forza devono
essere accessibili raggiungendo prima l’HQ, e poi dall’HQ raggiungendo le risorse esterne, potrebbe essere
utile e conveniente raggiungere direttamente utilizzando i collegamenti WAN che sono più economici, ma
che garantiscono minori SLA rispetto ai tradizionali servizi MPLS. Quindi la Digital trasformation è basata sul
riconoscimento delle applicazioni.

Concetto di break-down, significa qual è l’eccezione? quale traffico esce tranquillo dalla interfaccia fisica
come se nulla fosse? Creeremo un’interfaccia logica SD-WAN che rappresenterà l’utilizzo delle interfacce
fisiche.
Abbiamo creato una VPN IPsec S2S tra i 2 FG:
Includiamo porta2 e l’IPSEC Tunnel nell’SD-WAN.

SD-WAN lo troviamo nella sezione Network perché di fatto va a realizzare una interfaccia logica che
gestisce il traffico in uscita e quindi le corrispondenti policy based sulla base delle applicazioni tramite le
SD-WAN rules. Quindi l’impiego di un’interfaccia piuttosto che un’altra, sarà determinata dalla SD-WAN
rules che abbinerà le destinazioni definite appunto come applicazioni e i corrispondenti criteri per
selezionare le interfacce di uscita. Innanzitutto l’SD-WAN deve essere abilitato:

Quando inserisco delle interfacce nell’SD-WAN, dobbiamo assicurarci che queste non siano richiamate da
policy in uscita o altro oggetto tipo policy-based dell’IPSEC Tunnel (il richiamo a rotte statiche non
dovrebbe essere un problema), quindi dovranno essere pulite, perciò nel nostro LAB andremo a ripulirle.
Come Gateway delle porte fisiche dovremmo inserire l’indirizzo di next-hop a cui si riferisce l’interfaccia,
mentre come ben sappiamo, per le interfacce logiche e nel nostro esempio l’interfaccia tunnel, non è
necessariamente obbligatorio definire un indirizzo di next-hop come Gateway.

Andremo a creare una rotta statica che userà una rotta di default che devo far corrispondere alla nuova
interfaccia SD-WAN che abbiamo abilitato:
Quindi è chiaro che il nostro sito BRANCH, essendo il nostro Firewall, un Firewall di perimetro, avrà una
rotta di default che punta all’SD-WAN.

Prossimo STEP è definire i criteri per il quale le interfacce membro devono essere utilizzate:

Performance SLA, sta ad indicare con quale criterio devo giudicare buona un’interfaccia piuttosto che
un’altra: non è obbligatorio definire la Performance SLA perché c’è una categoria di regola SD-WAN che
permette la scelta sulla base delle priorità che indicherò nella regola. La Performance SLA è come lo SLA del
link-monitor o una sonda. Quindi nel Box “Server” possiamo inserire un IP per verificare la raggiungibilità di
una destinazione remota:

Fare attenzione al nome, a volte non accetta trattini o nomi troppi lunghi e quindi restituisce errore quando
andiamo a cliccare OK.
Queste performance SLA non sono attivi, saranno richiamati eventualmente dalle SD-WAN rules, queste
rules hanno anche un ordine di sequenza e devono fare in modo che la corrispondenza tra le applicazioni e
l’interfaccia WAN che va ad impegnare. I parametri definiti in un performance SLA come target sono
opzionali e quindi non sono richiamabili.

Mentre col Best Quality a prescindere dal raggiungimento dei Target SLA dobbiamo specificare il
performance SLA da richiamare, altrimenti non saprebbe dove andare a pingare. Quindi il Best Quality è le
migliori prestazioni ma solo su quel Server di destinazione che specifichiamo.
Col minimum quality è obbligatorio richiamare la Performance SLA, e nella regola SD-WAN affinché le
interfacce vengano matchate nell’ordine di preferenza devono essere raggiunti gli SLA Target.

N.B. L’ordine delle policy che andiamo a creare è importante e se per esempio, dovesse esserci una regola
che si sovrappone a quella seguente, andrà prima, quindi sarà effettiva la prima policy.

Una volta create le SD-WAN rules andremo a vedere su Routing Monitor che l’SD-WAN avrà inserito delle
policy routes per le SD-WAN rules:

In presenza di dubbio su quale sia l’interfaccia che viene impegnata da una particolare connessione da
parte del cliente, come si fa a selezionare con un “diag sniffer packet” quali sono le richieste di connessione
TCP?

Il TCP nel byte ha la posizione 13 è al 14° byte dell’intestazione fatto l’& logico con il numero 2
Vediamo che il filtro che ho inserito ha matchato soltanto i SYN e ha anche indicato le porte di uscita.
Questo è tutto traffico di richiesta connessione TCP perché ha un flag SYN. Perché è TCP 13?

Spiegazione campi della PDU di un segmento TCP:

Un’intestazione TCP ha un header lenght di almeno 5 righe da 4 byte, quindi ha un OVERHEAD minimo di
20 byte e sono tutte righe da 32 bit:

1 - La prima informazione in un segmento TCP è la porta Sorgente

2 - poi abbiamo la dst port

3 - poi senza distinzione abbiamo il sequence number, e come ben sappiamo, il TCP serve essenzialmente
per aggiungere informazione ad ogni singolo pacchetto IP perché possa poi ricostruire il flusso ordinato dei
byte

4 - poi c’è il numero di ACKNOWLEDGEMENT anche da 32 bit

5 - 4 bit che indicano l’header lenght, poi ci sono 6 bit riservati e poi ci sono i famosi flag del TCP e per
ultimo c’è il flag FIN che è la finalizzazione, e se è impostato ad 1 vuol dire che il mittente chiede di
terminare la connessione. Poi c’è il SYN, poi c’è il reset, poi c’è il push (quando un segmento richiede che il
buffer sia svuotato e i dati siano mandati all’applicazione), poi c’è l’acknowledgement e poi c’è l’URG
(URGENTE).
Quindi perché del byte ha la posizione 13? perché dei 6 bit riservati, 4 fanno parte del byte 12° e 2 fanno
parte del byte 13°, quindi avrò il 13° byte composto da questi 8 bit:

Quindi il segmento del SYN che è quello che ci interessa a Noi, dovrà avere 1 solo nel flag SYN e 0 in tutti gli
altri, e pertanto in binario vale 2:

Come infatti nel nostro filtro abbiamo messo il 13°byte e l’AND logico 2 (&2) che è un AND commerciale
che mi va a fare l’and logico con una configurazione binaria che vale 2.

Quindi questi 2 bit riservati + i 6 FLAG, facendo AND con 2, mi deve dare 2, quindi essenzialmente se c’è il
flag SYN impostato a 1 il filtro pcap utile è TCP[13]==2.

Quindi con questo controllo, utile a prescindere ma soprattutto quando utilizziamo SD-WAN, saremmo in
grado comunque in presenza di SD-WAN di capire la porta di uscita che sta funzionando.

Questo è molto utile in fase di troubleshooting, quando un cliente ci chiede come mai non sta funzionando,
e andiamo a vedere qual è l’interfaccia effettivamente impegnata.