Notre production NSX-T évolue et s’adapte de plus en plus à toutes nos contraintes opérationnelles. Récemment, il nous a fallu préparer l’arrivée d’une interconnexion entre des segments et un prestataire externe chargé de la supervision des machines connectées. Il a donc fallu se plonger rapidement dans le fonctionnement et l’implémentation d’IPsec pour mettre en place les tunnels associés. C’est comme si c’était fait !
Au tout début, gros malin que je suis, j’ai commencé à me pencher sur la documentation officielle ; après tout, n’étant pas un spécialiste de l’IPsec, je connaissait malgré tout pas mal la théorie et un peu la pratique. Assez, en tout cas, pour me dire : « allez, ça doit pas être si compliqué, on va regarder ça directement ». Maiiiiis, en fait, non ^^comme souvent avec la doc NSX-T, rien ne vaut un petit workshop très concret avec des experts. J’ai donc organisé une session de présentation de l’approche IPsec de NSX-T ainsi qu’une démo quasi « live » de la mise en place de tunnels. Au passage, un grand merci à Vincent, spécialiste NSX-T chez VMware, entre autre, de m’avoir concocté une présentation quasi parfaite pour ensuite reproduire cela en test chez nous. Au moins 50% de la cinématique de ce billet sur le sujet vient de sa présentation, rendons à César ce qui appartient à César !
On peut présenter la mise en oeuvre d’un tunnel IPsec en 4 étapes distinctes, selon moi :
– Préparation un petit schéma rapide pour visualiser les Tunnel à monter
– Création des profils de sécurité que l’on va utiliser ensuite pour construire les spécifications du Tunnel
– Mise en place du service VPN et du « local endpoint »
– Création de la session IPsec, qui permet d’établir le tunnel lui-même
… Et ben, vous savez quoi, allons-y !
Phase 0: schéma de principe
Vous savez quoi, comme je suis un gros fainéant, je vais utiliser l’outil génial « Topology » de NSX-T pour vous montrer ce qu’on va monter. Alors, ok, je fait un peu du retour vers le futur, mais au moins, le schéma est forcément exact, et en plus, il est assez explicite à mon avis :
L’objectif est de monter un tunnel IPsec entre mon TIER0 connecté à ma gateway pfSense, et autoriser un sous-réseau à l’intérieur de mon instance NSX, 172.28.1.0/24 à l’attention de mon réseau LAN, connecté derrière mon petit pare-feu. Du coté des endpoints IPsec, pas de mystère, il en faut 1 de chaque coté. Sur la pfSense, on a allumé directement l’IPsec sur la patte de sortie vers NSX, à savoir l’IP 192.168.254.1 (que vous voyez sur le schéma indiqué comme Remote EndPoint) et coté NSX-T, on doit donc créer un endpoint au bonne endroit pour terminer le tunnel. J’ai choisi de terminer celui-ci sur le TIER0, directement, mais il est tout aussi possible de choisir un TIER1 comme point de terminaison. Malgré tout, on en reparlera, faites attention à la combinatoire IP si vous êtes sur des IP publiques Internet, il faut réserver une IP par point de terminaison…
Pour l’exemple ici, vu qu’on ne sort pas sur le net et qu’on reste chez nous, tranquillou, on choisit une IP interne, la 172.28.0.1 pour le endpoint NSX. A noter qu’un endpoint NSX ne doit pas faire partie d’un réseau existant, évidemment, mais ne prend « qu’une ip ». A vous de vous choisir par exemple, une plage réservée à l’IPSec et piocher, dedans, à chaque fois que vous montez un nouveau endpoint.
Phase 1 : préparation des profils
La première chose à faire pour pouvoir construire effectivement le tunnel, c’est déclarer les « profils » qui vont être exigés lorsqu’on le créera effectivement. Il y a 3 profils à prépare : un profil IKE (pour la négociation des clefs typiquement), un profil IPsec (pour la mise en oeuvre des SA) et enfin un profil DPD, acronyme de Dead Path Detection, qui présente la stratégie de détection du fonctionnement du tunnel.
Je ne vais pas détailler tous les champs de chaque profils, si vous connaissez un minimum IPsec, tout doit vous parler ou presque, malgré tout, voici des extraits de ce que j’ai utilisé pour l’exemple et qui fonctionnent parfaitement :
Phase 2 : Mise en place du service VPN et du « local endpoint »
Maintenant, les choses sérieuses commence. D’abord, il va falloir « allumer » le service IPsec sur le routeur cible. Pour nous, l’objectif est de monter la terminaison IPsec sur le TIER0, directement. On va donc créer un « VPN Service ». Là, pas grand chose à rajouter, vous indiquez le TIERx que vous voulez utiliser, un pti nom pour la gloire, et c’est terminé.
Ensuite, on va créer le fameux « endpoint », c’est à dire le point de terminaison du Tunnel. Celui-ci va s’appuyer sur un VPN Service (celui qu’on vient de créer précédemment) et sur l’IP présentée plus haut, dans l’exemple la 172.28.0.1. Pas de masque ou de CIDR ici, car l’IP est toujours unique et routée en /32. Vous noterez que ce sur ce local endpoint qu’on indique l’ID IPsec. Traditionnellement, on met l’IP, mais on peut imaginer une chaine beaucoup plus complexe, pour plus de sécurité.
On est paré pour la dernière étape. Notre service VPN est monté, le endpoint est déclaré. les profils de chiffrement sont spécifiés.
Phase 3 : Création de la session IPsec
Allons-y, préparons notre session. Là, beaucoup plus de champs, évidemment, puisque que c’est que tout se met en place. Dans la partie supérieure du formulaire, on trouve notamment, les réseaux locaux et disants qui seront autorisés à se parler, l’IP désigné du service IPsec distant (ici ma pfSense), les information d’authentification, ici une simple preshared-key, l’identifant du service distant.
Dans la partie inférieur, les information plus techniques du tunnel lui-même, comme les profils créés précédemment IKE, IPsec et DPD, ainsi que la configuration sur la gestion des tailles de paquets qui seront sécurisés. La plupart du temps, on va choisir de pouvoir ajuster la taille des payloads car les paquets qui vont transiter on en général des tailles de 1500 octets. Il faut donc réaliser de la fragmentation pour les plus gros, histoire de ne pas dépasser les 1500 octets avec l’entête IPsec en plus.
Avec tout cela, normalement, on est bon ! Si vous vous êtes bien mis d’accord avec votre « partenaire » sur notamment les informations de chiffrement, la preshare-key et les réseaux qui transitent, le tunnel doit monter rapidement ! Attention tout de même, si vous choisissez de terminer vos tunnels sur vos TIER1, à bien vérifier que vos paramètres d’annonces de route sur ceux-ci ont bien « All IPsec local Endpoints » activé. Vous indiquez que le TIER1 doit prévenir son TIER0 de rattachement qu’il porte l’IP endpoint que vous avez choisi.
Si on NAT, ça fait quoi ?
Un des objectifs de mes essai était de valider le fonctionnement d’un tunnel IPsec à l’intérieur duquel on va devoir NATer un ou plusieurs des réseaux qui transite. Ce genre de chose n’est pas si rare que cela quand vous gérer des connexions externe avec de nombreux partenaires. Vous pouvez être confrontés à des conflit au sein même des tunnels à monter. Si vous revenez à la définition de la session IPsec, vous avez pu voir que contrairement à ce que je vous ai précisé en introduction, ce n’est pas un subnet, le 172.28.1.0/24 mais DEUX subnet différents, l’original et un second 172.26.1.0/24. En fait, ce dernier est également autorisé à transiter sur le tunnel, car il s’agit d’un NAT 1-1 vers le réseau initial, le 172.28.1.0/24 ! Je sais, je suis un petit canaillou ^^
Comme vous le voyez, l’ensemble du subnet 172.28.1.0/24 et SNAT/DNAT avec le 172.26.1.0/24. Dans la pratique, cela veut dire qu’en attanquant une IP 172.26.1.100, en fait, on s’adresse dans la pratique au 172.28.1.100 (et inversement). Le NAT est porté par le TIER1 et le TIER0 s’occupe de terminer le VPN et router tout ça. Et ça marche :) . Evidemment, ce NAT peut aussi être porté directement par le même routeur qui porte le local endpoint.
Il reste à parler du choix de la termination : sur un TIER1 ou un TIER0. Il parait légitime au premier abord de privilégier le TIER1 pour localiser les terminaisons IPsec directement sur les réseaux de vos clients/tenants. Le problème se pose au sujet du « local endpoint ». Si vous avez la chance d’allouer un pool d’ip publiques pour chaque client, pas de souci, vous en réservez une sur le TIER1 et le tour est joué, d’autant que vous pouvez continuer d’utiliser cette même IP pour du NAT autre qu’IPsec. Cependant, vu la pénurie des ranges d’IPv4 disponibles actuellement, j’imagine que vous faites, comme nous, très attention à l’usage de cette resource rare. De facto, la question se pose de mutualiser le end point et donc de privilégier le TIER0 comme support à vos terminaisons IPsec. C’est globalement un choix de compromis que vous devrez faire : rationaliser les IP publiques ou privilégier l’isolation logique des fonctions de chaque client.
Pour terminer, et cela n’a rien à voir avec le sujet de ce billet. Vous avez sans doute remarqué que j’ai utilisé une « vidéo gif » grâce à un petit outil share que je vient d’acquérir. Je veux bien votre retour, car je pense que ça peut illustrer de manière beaucoup plus dynamique ce genre de billets techniques. Merci de m’avoir lu et passez un bon week-end (pour ce qui me liront le 12, 13 ou 14 Mars 2021 prochains ^^
Portez-vous bien !