Notes sur la technologie SD-WAN de Fortinet
Introduction
Je viens de passer plusieurs jours à tester la technologie SD-WAN de Fortinet sur des Fortigate (90D et 101E, FortiOS 6.0.3) à travers différents LAB/scénarii. Je dois dire que je suis assez bluffé dans l’ensemble.
Une fois que l’on comprend la logique/philosophie, on se retrouve finalement avec moins de règles de filtrage à gérer et qu’une seule route par défaut quasiment. Il devient alors possible de s’affranchir d’utiliser un protocole de routage dynamique type OSPF, de réduire le temps de bascule en cas de défaillance d’un lien et de gérer finement les flux applicatifs.
J’ai tout de même rencontré quelques soucis lors de la mise en oeuvre que je voulais partager avec vous dans ce billet…
Les stratégies SLA et leur application avec SD-WAN
L’une des forces de cette dernière version du FortiOS 6.0 est la gestion intelligente des liens en s’appuyant sur des SLA que l’on peut combiner : RTT, Jitter et nombre de paquets perdus etc…
On peut également choisir, voire définir, la stratégie à appliquer sur notre flux :
« Best Quality » sera plutôt utilisée pour les services de type VoIP, Fortigate utilisera toujours le lien avec les meilleurs exigences en matière de SLA, quel que soit le coût de la liaison. On recherche les meilleures performances pour les applications critiques.
On peut ainsi définir le critère de qualité principal à retenir voire de créer un profile spécifique avec nos critères :
On peut également privilégier un lien pour l’upload et/ou le download.
« Minimum Quality (SLA) » servira pour le reste du trafic, où l’on considérera aussi bien le SLA que le coût du lien. A noter qu’ici l’ordre de priorité des interfaces à son importance, si toutes les interfaces répondent aux critères de SLA, Fortigate utilisera le premier lien, même si ce n’est pas le meilleur.
Un exemple ici avec 2 liens VPN IPSec : J’ai simulé un lien dit « public » qui passe par Internet avec un RTT moyen de ~20ms et un second lien dit « privé » avec un RTT inférieur à <1ms
Dans ma stratégie j’ai volontairement choisi le lien avec le moins bon RTT en premier :
A noter qu’il faut (souvent) se méfier de l’affichage via le GUI, il pourrait ne pas être représentatif de ce que l’on veut. Il est préférable de vérifier le résultat via CLI :
Ensuite, un simple ping vers la Loopback du Fortigate distant nous confirme le lien utilisé :
Mon LAB de test
Parmi les différents tests réalisés, j’ai retenu ce LAB. C’est le cas le plus simple où on a 2 sites reliés ensemble par 2 liaisons :
Chaque site possède son propre accès Internet. Ces sites sont reliés entre aux par 2 VPN IPSec :
- Un VPN établi via les liens « publics » ISP 1 et ISP 2 d’une latence de ~20ms
- Un VPN établi via les liens « privés » 172.[1-2].10.0/30 d’une latence de ~1ms
La configuration des Fortigate est symétrique au niveau des règles de firewall et SLA de telle sorte que chacun des sites puisse joindre le second et accéder à Internet:
- 3 interfaces (VPN x2 + Interface WAN) dans le SD-WAN, avec comme route par défaut, la liaison SD-WAN justement
- 2 règles SLA pour gérer la performance :
- L’une vers Internet avec comme serveur cible le DNS Google 8.8.8.8 comprenant les 2 interfaces WAN (pas très utile car nous avons qu’un seul lien Internet mais c’est pour la forme)
- Et la seconde vers la loopback du site distant, comprenant les 2 VPN IPSec
- 2 règles SD-WAN de type « Minimum Quality » :
- L’une pour l’accès Internet, comprenant nos interfaces WAN, utilisant notre première règle SLA
- La seconde pour atteindre le PC distant, comprenant nos VPN, utilisant notre seconde règle SLA
Pour la seconde règle SD-WAN j’ai volontairement mis en premier le lien public avec une latence 25ms car je voulais observer le comportement des Fortigate lors du basculement des liens. Il suffisait de « secouer » le lien Internet pendant quelques secondes pour forcer la bascule sur le lien privé, j’utilisais pour cela le site de Netflix qui mesure la bande passante : https://fast.com/fr/
Pour permettre l’établissement du VPN sur le lien privé, j’ai du ajouter une route statique de part et d’autre afin de pouvoir atteindre chacun des subnets. Par exemple sur le site 1 :
La route par défaut de chacun des laptop est le Fortigate auquel il est relié.
Dernier détail qui aura son importance dans le point suivant, je n’utilise que le VDOM « root ».
Problèmes rencontrés et solutions
Déconnexion SSH et timeout HTTP(S)
Durant mes tests je perdais régulièrement la connexion vers le Fortigate distant. Par exemple, depuis le laptop 172.16.10.100 je me connectais sur la loopback du Fortigate du site 1 (10.66.255.1) et je perdais la connexion d’un coup. De même que la connexion HTTPS sur le Fortigate figeait puis revenait. J’ai ensuite essayé sur l’interface d’interconnexion du Fortigate (172.1.10.1), même chose, ainsi que sur l’interface publique.
Par contre, je ne perdais pas les connexions entre les 2 laptops. J’étais par exemple connecté via Remote Desktop (RDP) sur le laptop du site 1 (192.168.1.100), toujours depuis l’autre laptop et je ne constatais aucune déconnexion ou timeout…
Je me suis en fait aperçu, qu’à chaque fois que l’un des Fortigate changeait la route pour atteindre le site distant, je perdais la connexion… j’ai fait le parallèle en lançant un ping en continue entre les 2 laptop, comme ici où l’on passe du lien public au lien privé :
N’ayant pas de solution à ce problème dans l’immédiat, j’ai contacté le support Fortinet. Le support m’indique qu’il s’agit tout simplement d’une sécurité, car une session établie par une interface (Ex. liaison « publique »), ne peut ensuite se retrouver sur une autre (Ex. liaison « privée »)…Et ce problème ne concerne que les connexions faites sur le Fortigate, cela ne concerne pas les autres flux qui le traversent.
Ok mais cela ne m’arrange pas ça ! En effet, j’administre des Fortigate un peu partout dans le monde, notamment en Afrique où nous utilisons différentes liaisons satellites qui sont sensibles au mauvais temps et dont les performances sont aléatoires (latence, jitter…). Je ne me vois pas en production avec ce genre de comportement…Et surtout ce phénomène se produit systématiquement dès que l’on modifie quelque chose au niveau des fonctionnalités SD-WAN…
Et bien-sur le support n’a pas de solution à cela ! Enfin si, il me propose :
- Demander à mon commercial de faire une demande de développement d’une fonction par Fortinet pour gérer ce cas
- Mais bien-sur…et la marmotte…
- De permettre le routage asymétrique (désactiver la fonction « asymmetric check routing »)
- super pour la sécurité, les règles de firewall ainsi que les fonctions UTM ne sont plus utilisées…on se retrouve juste avec un simple routeur
J’ai finalement trouvé une solution : mettre les interfaces SD-WAN dans un VDOM à part (Ex. SD-WAN) et laisser l’interface loopback dans le VDOM « root »
C’est tout bête, il suffit ensuite de créer un VDOM Link et d’ajouter une route statique, comme ici sur le Fortigate du site 1 :
VDOM « SD-WAN » :
VDOM « root » :
Pour finir, on crée les règles de firewall et le tour est joué :
VDOM « SD-WAN » :
VDOM « root » :
Comme cela, même si l’interface utilisée change (publique vs privée), le Fortigate utilisera toujours cette unique interconnexion des VDOM pour atteindre la loopback.
Routage asymétrique
On parle de routage asymétrique lorsqu’un paquet n’emprunte pas le même chemin à l’aller et au retour.
J’ai également pu constater ce phénomène avec un simple ping et traceroute entre les 2 laptops :
Dans le même temps j’ai comparé comment se comportait ma session RDP vers le laptop du site 2, 172.16.10.100 :
Là le routage est symétrique, cela me rassure « un peu » plus. En effet, seul le protocole ICMP semble concerné par ce phénomène (le commande tracert windows utilise ce protocole également). Au niveau TCP/UDP avec RDP, c’est à la source qu’est « décidé » sur quel lien la session doit transiter aller/retour, dans notre cas c’est le Fortigate du site 1 avec le lien « public ».
Si j’ai bien constaté que la session se baladait d’un lien à l’autre, à aucun moment je n’ai vu les 2 liens utilisés en même temps pour les connexions TCP/UDP RDP, contrairement à ICMP.
Ce qui me dérange par contre, c’est pour les outils de supervision. Et oui, on utilise souvent le ping pour surveiller qu’un host distant est Up et surveiller la latence. Du coup, avec ce type de comportement le résultat risque d’être biaisé.
Rien de grave mais il faut avoir cela en tête. Et puis je pousse le vis en choisissant volontairement le lien le plus mauvais en premier avec des critères proches des limites du lien.
Et dernière chose, dans ce cas si il s’agit du même Fortigate qui a déjà connaissance d’une session dans sa table. Le routage asymétrique se produit surtout lorsque deux firewall distincts sont traversés, et le flux se trouve bloqué par sécurité.
