NSX-T : Mais que se passe-t-il avec le DNAT ?

Youhou ! Nous sommes enfin en production sur NSX-T ! après des mois de préparation, des reports indépendants de notre volonté, mais aussi récemment un dernier souci bien étrange qui nous a obligé à repousser encore de quelques semaines supplémentaires cette grande échéance … mais, Dieu me tamponne, quel était donc ce “dernier souci” ? Je vous en dit un peu plus ? Mais bien sûr, c’est bientôt Noël en plus !

Que je vous explique.

Dans le cadre de notre premier workload de production sur NSX-T, nous avions besoin, pour des raisons de migration et des raisons historiques, d’effectuer ce qu’on appelle dans notre jargon local un “double NAT”. Dans la pratique, il s’agit de faire router des flux IP depuis une machine rapatriée dans notre DC mais qui doit continuer à discuter avec des VM qui “restent chez le client”. Etant en mode routé et pas en mode L2, il nous faut transiter via un réseau d’interconnexion qui ne connait pas l’adresse réelle du destinataire. Ca se fait assez souvent je pense, et nous traduisons cela en interne par un Destination-NAT du paquet émis (transformant l’ip cible legacy en ip compatible avec le routage sur le réseau d’interconnexion), puis en effectuant un nouveau Destination-NAT en arrivant sur le parefeu/équipement périmétrique du client, histoire de redonner au paquet sa destination initiale. Le retour du paquet est en principe sans effort puisqu’assuré par les routeurs statefull du coté client mais aussi forcément du coté de NSX-T.

Jusque là, certes, c’est de la “bidouille” mais c’est sensé marcher dans la majorité des cas, sauf pour les protocoles des années ante-diluviennes avec des IPs codées en dur dans les payloads, genre ces monstruosités comme H323, au hasard (sauf si vos firewall son très intelligents). Mais bon, chez nous, pas de protocoles de ce type, de la banale session TCP classique.

Les ennuis commencent.

Nous avions donc à implanter cela pour un certain nombre de serveurs et d’imprimantes distantes restant sur site, lors de la bascule et de la mise en production. Vous l’imaginez, après le teasing du paragraphe précédent, tout ne s’est pas passé comme prévu. Je vous fait grâce des heures de debugging et traces diverses, les suspicions sur certains équipements qui en fait n’y étaient pour rien… pour arriver à la conclusion qui s’est imposée à nous au bout de plus de 2 jours : NSX-T avait un problème avec nos DNAT. Enfer, damnation, NSX-T avait un souci de bête Firewall ? Je n’y croyais pas moi-même au départ…

Nous avons donc fini par contacter le support VMware. Comme quasi à chaque fois, celui-ci a été exemplaire (grand respect à Fabien pour son opiniâtreté et son professionnalisme, il se reconnaîtra) et après de longues analyses en liaison avec l’engineering, il confirme comme nous qu’EFFECTIVEMENT, NSX-T a un souci plus qu’embêtant avec le DNAT que nous avons mis en place : l’aller se passe bien, mais au retour, la réponse TCP n’est pas Dé-DNATée (quel joli nom). En somme le DNAT se comporte comme s’il n’était pas statefull. Du coup, Fabien nous propose de réaliser un SNAT pour le retour, sans effet malheureusement. Le problème semble donc plus profond que cela.

Après encore quelques temps d’investigation, vient une seconde prise de traces suivi par une nouvelle tentative de workaround : la hotline nous a proposé de désactiver une partie des optimisations présentes dans les Edge Nodes impliquées et bingo, nos DNAT se sont mis à fonctionner “comme prévu sur tous les firewall du monde de l’univers dans son ensemble et même plus”. La commande en question est simple, mais non documentée publiquement et je ne préfère honnêtement pas vous la donner pour le moment, tant que je n’ai pas plus d’info sur l’innocuité de celle-ci sur l’ensemble des fonctions de NSX.

Il semblerait (notez le conditionnel, ce sera utile pour ma conclusion provisoire) que le problème soit lié à un algorithme d’optimisation de routage au sein des Edge Nodes. Sans rentrer dans les détails (auxquels d’ailleurs je n’ai pas encore accès), en gros, de ce que j’ai compris (notez les précautions, messieurs-dames), lorsque le paquet TCP synack arrive en retour, la Edge constate au niveau du DR TIER0 qu’elle connait la source VM, celle qui a émis le TCP syn, et route directement à la destination via le DR TIER1… et bypass du même coup les SR ! Comme ça, paf, sans se poser de question… non, mais, allo ? Aheum, désolé je m’emporte et j’ai promis de rester posé (j’ai pris quelques cachets au passage… gnnnnh).

Un petit schéma synoptique valant mieux que de longs discours, voici en gros ce qu’on constate :

C’est l’heure du premier bilan.

Nous avons donc un souci chez nous, le DNAT dans le sens Interne NSX vers Externe fonctionne à l’aller, mais se comporte comme non statefull au retour. Soit. Nous avons une solution de contournement qui marche chez nous. Soit. Peut-on dans ces conditions donner le go, enfin, pour la mise en production.

Et bien la réponse est OUI, grâce aux discussions avec notre TAM, David, mais aussi avec Fabien du support VMware, ainsi que l’ensemble de l’équipe projet de notre coté. Les tests préalables post contournement se sont révélés plus que concluants, aucun souci avec des DNAT/SNAT dans tous les sens, pas d’impact visible sur les performances à notre petit niveau, bref, même si le problème n’est clairement pas définitivement résolu, les signaux étaient au vert et il fallait y aller. C’est d’ailleurs une production sans aucun souci depuis plus d’une semaine maintenant qui vient le confirmer.

Maintenant, qu’est-ce qu’il se passe vraiment avec les DNAT sur NSX-T?

La première chose sur laquelle je veux insister ici c’est qu’à l’heure actuelle on ne peut pas dire que c’est “juste un bug” ou quelque chose de spécifique chez nous (même si, quand même, tout le monde a de fortes présomptions sur l’issue de ce problème, autant chez nous que chez VMware). On ne peut pas encore exclure que ce ne soit pas une conjonction de facteurs. Par contre, nous avons au moins une certitude aujourd’hui : VMware travaille d’arrache pied sur ce sujet et nous a confirmé que les DNAT “SUD-NORD” fonctionnent, eux, parfaitement. Typiquement si vous vous servez du DNAT pour faire de la translation de port entrant pour un service exposé sur le net par exemple, vous n’aurez aucun souci. Au passage d’ailleurs, c’est le fait que nous utilisions précisément le DNAT pour cela aussi que le souci nous a rendu aussi dubitatif au départ.

Deuxièmement, il s’agit sans doute déjà d’un incident en “critical” chez eux et nul doute qu’un fix/patch n’arrive prochainement pour au moins clarifier voire résoudre la situation.

Troisièmement, après un focus initial exclusif sur la version 2.5, il n’est plus certain que cela ne puisse pas non plus arriver sur les version précédentes, preuve, encore, que l’investigation se poursuit et que le symptôme que nous avons rencontré n’est peu-être pas uniquement lié à la fonction DNAT.

Enfin, et pour finir, enfoncer le clou, damer le pion, faire taire les zozios de mauvaise augure, la rumeur et calmer nos chers collègues des U.S. ^^, sachez qu’il m’aura fallu du temps et quelques conseils pour finalement accoucher de ce billet sans doute “sensible”, alors même que VMware n’a pas encore officiellement communiqué sur le sujet (à l’heure où je publie ces lignes, le 16 Décembre 2019). En cela, je remercie fortement les personnes avec qui j’ai pu discuter, notamment chez VMware, pour jauger si c’était le bon moment ou pas. Qu’on soit encore plus clair, Il ne s’agit en aucun cas d’un billet à charge, mon rôle aujourd’hui est juste, comme très souvent ici, de communiquer avec mes homologues, les alerter, pour, dans la mesure du possible, éviter que ce qui nous arrive ne se produise chez eux. Si une petite alerte de temps en temps peut éviter cela, je serai le plus heureux des professionnels ^^

NDLR: Au passage, si je pouvais en faire autant en lisant plus de blogs en français, ça serait pas mal… allez, lancez-vous, mesdames, messieurs les archis/spécialistes francophones !

Conclusion : dans les semaines qui viennent, si vous avez des comportements “bizarres” avec des DNAT sur NSX, ne vous posez pas de question et ouvrez tout de suite un SR chez VMware. Il est possible que vous soyez victime du même dysfonctionnement que nous. Vous économiserez de l’énergie et sans doute des heures de travail. Vous pouvez faire référence à ce post éventuellement, en particulier si vous tombez sur des Frenchies (il y en a beaucoup au support NSX et tous ceux que nous avons eu sont excellents).

Je mettrai bien sûr ce billet à jour dès que j’aurai des nouvelles infos publiques à vous donner ainsi que des liens vers les KB/Fixes officiellement annoncés (le SR est encore ouvert chez nous et j’ai des contacts réguliers VMware pour avoir le fin mot de l’histoire).

C’était un peu plus long que d’habitude, désolé ^^
Donc, merci de m’avoir lu jusqu’au bout !
Maintenant, c’est public, vous pouvez lancer la machine à troll …

EDIT du 19/12/2019 : VMware vient de documenter le KB#76562 sur ce problème. Comme vous pouvez le consulter, il n’y a pas de résolution et la fameuse commande dont je vous ai parlé n’est toujours pas officiellement publique. Je ne sais pas trop quoi en penser, mais un fix est d’ores et déjà en préparation. Si vous êtes malgré tout bloqué en prod à cause de cela, n’hésitez pas à me contacter. A suivre !

EDIT du 20/12/2019 : NSX-T 2.5.1 est out ! De nombreux bugs (70% de ceux référencés) par contre, le bug DNAT n’est toujours pas fixé.