Vous le savez, le NAT, c’est notre grande passion, en particulier sur NSX-T ^^. Nous avons tellement de cas “legacy” qu’il nous faut intégrer lors des différents chantiers d’hébergement, que ce bon vieux NAT est une nécessité au moins temporaire, n’en déplaise à tous les brillants ingénieurs réseau avec qui je discute régulièrement… Du coup, on commence à bien connaître les ficelles (et les bugs, cf le bug DNAT découvert en décembre dernier) du système éponyme sur notre SDN favori. Je vous propose encore une nouvelle astuce, pour intégrer NAT/NoNAT dans vos workflows réseau.

En effet, il arrive assez régulièrement dans le monde des firewalls périmétriques que vous deviez faire des exceptions à une règle de NAT générique, pour certaines destinations réseau. Ces exceptions au NAT doivent absolument être traitées par le routeur AVANT la règle de NAT générique. Or, comme souvent, la documentation officielle de NSX-T ne fourni que des cas “bâteau” et non contextualisés. Il a donc fallu se débrouiller pour comprendre comment ça marchait exactement et trouver les bon paramètres.

Contrairement aux règles de firewall, sur NSX-T, l’ordre de vos NAT ne sont pas dynamique dans l’interface graphique, vous ne pouvez pas les remonter ou les descendre, pour en gérer graphiquement la priorité, justement. Pour le coup, il nous a fallu quelque temps pour repérer enfin le champ “priority” dans chaque règle de NAT et ainsi ordonnancer correctement nos règles, à la main.

Vous disposez donc d’un champ ad-hoc qui affecte un numéro de priorité à chaque règle de NAT (SNAT/DNAT/No SNAT/No DNAT). Plus le nombre est petit, plus la priorité est importante. Ainsi, vous pouvez enfin gérer correctement un “no SNAT” devant un “SNAT” par exemple, pour nater un flux de sortie pour “la majorité” mais ne pas le faire pour un réseau ou un host spécifique.

Amusez-vous bien …
… et bonne année à tous !