Travailler les paramètres IPsec de vos tunnels sur NSX-V (feat. Mika)

Bonjour à tous. Un petit “back-to-the-future” avec ce billet technique. Certes, nous ayons déjà pris le virage de NSX-T depuis un moment déjà, malgré tout il nous reste toujours notre plateforme d’hébergement où se trouve une grosse partie de nos partenaires et clients (HDS oblige). Cette plateforme est basée sur vCloud Director/NSX-V depuis plus de 6 ans maintenant. Dans ce contexte, je vous propose un petit retex sur des incidents récents concernant un tunnel IPsec un peu récalcitrant monté sur une Edge Gateway.

En effet, nous avons été confronté, il y a quelques semaines, à des instabilités sur un tunnel IPsec monté récemment entre la Edge Gateway d’interco d’un environnement d’hébergement et l’équipement de sécurité périmétrique du client concerné. Malgré nos premières investigations, nous ne trouvions pas ce qui clochait : le tunnels montait correctement, mais au bout d’un temps donné (une heure dans notre cas), celui-ci retombait systématiquement, faisant tout de suite penser à un problème de paramétrage de timeout/lifetime entre les deux partenaires IPsec. Pour autant, cela a été plus compliqué que prévu. Histoire de ne pas patauger des jours sur ce souci spécifique, on a préféré contacter un de nos partenaires historiques sur les technologies VMware : Axians Cloud Builder.

Et, dites, vous savez quoi ? Pour la première fois sur ce blog, je vais laisser directement l’expert parler ! Je vais l’appeler “Mika”, il se reconnaîtra évidemment et sans doute aussi la plupart de ses collègues, mais, Internet oblige, restons discret sur sa réelle identité :) . La suite est une transcription fidèle de son compte-rendu, juste un peu aménagé et ré-écrit en partie pour rendre cela plus facile à lire (avec des petites mentions NDLR de bon aloi). Bonne lecture !

Le lien VPN montait sans problème mais tombait invariablement au bout d’une heure. Il fallait relancer manuellement celui-ci pour restaurer la connexion entre le firewall du client et la edge gateway. Cette durée de 60 minutes était trop régulière pour ne pas être un timeout spécifique à liaison VPN.

Un des paramètres semblait être un coupable potentiel : le SA lifetime. Une petite recherche sur le Net (NDLR: google est ton ami, il faut l’aimer rossi) m’a confirmé que les edges NSX-V avaient un SA Lifetime de 24h, tandis que celui de Checkpoint (le pare-feu du client) était de 1h. Une fois ce paramètre corrigé, on a constaté que la session VPN montait et restait bien up passé l’heure fatidique. Oui mais non …

Si la session VPN semblait montée, les flux internes étaient tout de même coupés au bout d’une heure. C’est plus insidieux : pas d’alerte de session VPN perdue, mais le tunnel devenait inopérant. Avant d’aller plus loin, petit rappel théorique sur le “comment qu’c’est’y qu’cela fonctionne” pour une session VPN IPsec :

Les deux extrémités d’un tunnel VPN IPSec sont des pairs IPSec. Pour construire la session VPN, les pairs IPSec échangent une série de messages sur le chiffrement et l’authentification. Ils tentent de se mettre d’accord sur de nombreux paramètres différents. Ce processus est connu sous le nom de négociations VPN (NDLR: les phases IKE). Dans notre cas, le checkpoint est l’initiateur et la edge NSX-V le répondeur. Les négociations VPN se déroulent en deux phases distinctes.

IKE Phase 1 : L’objectif de cette première phase est de mettre en place un canal sécurisé par lequel les deux pairs peuvent négocier des paramètres complémentaires en phase 2. Lorsque la phase 1 se termine avec succès, les pairs passent à la phase suivante, sinon, le tunnel tombe de suite, évidemment.
Les paramètres de la négociation sont les suivants :
Authentification – Le type d’authentification (SHA1, SHA2, MD5, …)
Chiffrement – Le type d’algorithme de chiffrement (DES, 3DES, AES, …)
SA Lifetime – Le temps qui s’écoule avant l’expiration de la phase 1 de l’association de sécurité.
Groupe de clés – Le groupe de clés Diffie-Hellman.

IKE Phase 2 : Les deux pairs s’accordent sur un ensemble de paramètres qui définissent la sécurisation du trafic interne du VPN lui-même, et donc la manière de le chiffrer et authentifier. Cette négociation s’appelle l’association de sécurité (NDLR: Security Association, “SA”). Les configurations des phases 1 et 2 doivent donc parfaitement correspondre entre les deux partenaires techniques.
Les paramètres de la négociation sont les suivants :
Type – le type de protocole à utiliser (Authentification Header (AH) ou Encapsulating Security Payload (ESP)) ESP la plupart du temps.
Chiffrement – Le type d’algorithme de chiffrement (DES, 3DES, AES, …)
SA Lifetime – Le temps qui s’écoule avant l’expiration de la phase 2 de l’association de sécurité.
Authentification – algorithme que les pairs utilisent pour authentifier les messages IKE (SHA1 ou MD5).

Par définition, le temps avant l’expiration de la phase 1 doit être égal ou supérieur à celui de la phase 2. Dans notre cas, nous n’avions modifié que le SA Lifetime de la phase 1, celui de la phase 2 n’étant pas accessible via les GUI VMware. Le VPN restait online, mais les flux transitant par ce VPN n’était plus chiffrés (timeout de la phase 2 atteint d’un coté, mais pas de l’autre) et donc bloqués.

Sous vSphere, dans la section “Network and Security” (NSX-V, donc), nous avons accès à quelques paramètres de la Edge NSX-V via l’interface en Flash, mais pas la totalité malheureusement. Il fallait donc utiliser la granularité de configuration supérieure coté Checkpoint pour arriver à faire coïncider les spécifications de la phase 2 sur chaque pair.

Comment savoir quel timeout de phase 2 exact était placé sur la Edge ? En fait, il existe une fonction très pratique dans la section Edge de vSphere : l’export de la config VPN pour un initiateur Cisco ASA ! Nous avons donc pu récupérer tous les paramètres ad-hoc pour la session VPN. Grâce à cela, on a pu avoir une configuration cohérente, notamment en terme de timing, entre la Edge et le Checkpoint. Le Tunnel est complètement stable depuis !

Grand merci à Mika pour son expertise et sa perspicacité durant cette phase d’analyse. On a encore appris des trucs pendant cette journée ! J’aime mon travail :)