Réseau virtuel : NSX et pfSense pour une infrastructure virtualisee

Dans un cluster de virtualisation, le réseau n’est pas un simple plan de transport entre machines virtuelles. Il conditionne la disponibilité des services, la mobilité des charges, la sécurité des flux inter-applicatifs et la capacité à diagnostiquer les incidents. Une architecture réseau mal pensée transforme rapidement un incident limité en panne généralisée : perte de management des hôtes, vMotion indisponible, stockage inaccessible, isolation des nœuds ou exposition involontaire de services d’administration.

Le point de départ consiste à séparer les fonctions réseau, puis à choisir les mécanismes adaptés à leur niveau de criticité. Les réseaux de management, de vMotion, de stockage, de réplication, de sauvegarde et de production n’ont ni les mêmes exigences de sécurité ni les mêmes profils de trafic. Dans un environnement VMware vSphere, cette séparation peut s’appuyer sur des vSwitch standard, un vSwitch distribué vDS, des VLAN, et, lorsque le besoin est justifié, sur la micro-segmentation fournie par VMware NSX. Pour les homelabs et les petites infrastructures, un pare-feu virtualisé tel que pfSense peut également fournir le routage inter-VLAN, le filtrage périmétrique, les VPN et certains services réseau, à condition de ne pas créer de dépendance circulaire dangereuse.

Ce guide détaille les choix d’architecture les plus fréquents, les compromis opérationnels et les contrôles à appliquer pour bâtir un réseau virtuel robuste. L’objectif n’est pas de reproduire le réseau physique dans l’hyperviseur, mais de tirer parti de la virtualisation tout en conservant des frontières de sécurité claires, des chemins de secours testables et une exploitation prévisible.

Cartographier les flux avant de créer des port groups

Avant de créer des VLAN ou des réseaux logiques, il faut identifier les flux, leurs sources, leurs destinations et leur criticité. Cette étape évite le schéma classique où un unique VLAN transporte indistinctement le management, les machines virtuelles, le stockage et les sauvegardes.

Dans un cluster, les catégories habituelles sont les suivantes :

• Management des hyperviseurs et de vCenter.
• vMotion et, le cas échéant, vSphere Replication.
• Stockage IP : NFS, iSCSI, NVMe over TCP ou vSAN.
• Réseaux de machines virtuelles de production.
• Réseaux DMZ ou exposés.
• Sauvegarde, restauration et réplication.
• Administration hors bande : iDRAC, iLO, BMC, consoles de commutateurs.
• Services d’infrastructure : DNS, NTP, PKI, bastion, supervision, syslog.

Le découpage ne doit pas être motivé uniquement par une recherche de performance. Un VLAN isole le domaine de broadcast et structure le routage, mais il ne remplace pas une politique de sécurité. Dès qu’un routeur ou un pare-feu autorise largement les flux entre VLAN, la segmentation devient largement théorique.

Définir des zones de confiance

Une approche utile consiste à raisonner en zones :

Cette cartographie sert ensuite à définir les VLAN, les règles de pare-feu Nord-Sud et, si NSX est utilisé, les règles Est-Ouest du firewall distribué.

Prévoir les dépendances cachées

Les dépendances réseau critiques sont parfois invisibles lors de la conception initiale. vCenter dépend du DNS, de NTP et des hôtes ESXi. Les hôtes peuvent dépendre d’un serveur NTP, de syslog, d’un serveur d’authentification et parfois d’un stockage partagé. Les outils de sauvegarde ont besoin de joindre les hôtes, les vCenter, les VM, les dépôts et éventuellement les proxies.

Documentez au minimum :

• Les sous-réseaux, passerelles, plages DHCP et adresses statiques.
• Les ports TCP et UDP nécessaires aux services d’infrastructure.
• Les interfaces physiques utilisées par chaque type de trafic.
• Les règles de filtrage associées.
• Les dépendances qui doivent continuer à fonctionner en mode dégradé.

vSwitch standard et vSwitch distribué : choisir le bon modèle

VMware propose deux modèles principaux de commutation virtuelle : le vSwitch standard, souvent appelé vSS, et le vSwitch distribué, ou vDS. Les deux assurent la connectivité des VM et des interfaces VMkernel, mais leur portée opérationnelle diffère fortement.

Le vSS est configuré localement sur chaque hôte ESXi. Chaque hôte possède ses propres port groups, politiques de teaming, paramètres de sécurité et uplinks physiques. Il est simple, disponible sans dépendre d’un vCenter opérationnel pour son fonctionnement courant, et particulièrement adapté aux environnements réduits. Pour aller plus loin, consultez la sécurisation d’un cluster de virtualisation.

Le vDS est géré de manière centralisée depuis vCenter. Il applique une configuration cohérente à l’ensemble des hôtes membres et offre des fonctions plus avancées : port groups distribués, LACP, Network I/O Control, port mirroring, NetFlow/IPFIX selon les versions, sauvegarde cohérente de configuration et intégrations nécessaires à certaines fonctions NSX. La documentation technique centralisée sur le portail TechDocs Broadcom reste la référence pour les paramètres précis d’une version donnée de vSphere.

Quand conserver un vSwitch standard

Même dans un environnement utilisant un vDS, conserver un vSS dédié au management peut être un choix défensif pertinent. L’idée est de garantir un chemin de récupération local si une erreur de configuration affecte le vDS, vCenter ou les uplinks partagés.

Un schéma fréquemment utilisé consiste à :

• Héberger les VMkernel de management sur un vSS.
• Réserver deux interfaces physiques au management si le matériel le permet.
• Utiliser un vDS pour les réseaux VM, vMotion, stockage et réseaux NSX.
• Maintenir une procédure d’accès direct à l’interface de management ESXi, y compris via console hors bande.

Ce n’est pas une obligation universelle. Dans une architecture mature, le management peut être porté par un vDS. Mais il faut alors maîtriser les mécanismes de rollback, disposer d’un accès hors bande et tester les scénarios de perte de connectivité vCenter.

Migration vers un vDS sans perte d’accès

La migration doit être progressive. Commencez par créer le vDS, ajoutez les hôtes, créez les port groups distribués avec les VLAN corrects, puis migrez un uplink et un vmnic à la fois.

Points de contrôle essentiels :

1. Vérifier le mode trunk sur les ports physiques concernés.
2. Confirmer que tous les VLAN nécessaires sont autorisés sur chaque lien montant.
3. Migrer une interface à la fois et tester la connectivité.
4. Ne pas déplacer simultanément tous les uplinks du management.
5. Conserver un accès de console physique ou hors bande.
6. Exporter la configuration réseau avant toute modification.

Segmenter avec les VLAN sans créer une fausse sécurité

Les VLAN restent le socle de la segmentation réseau dans la plupart des infrastructures. Sur ESXi, chaque port group est associé à un VLAN ID, tandis que les uplinks vers les commutateurs physiques fonctionnent généralement en trunk 802.1Q.

Un modèle simple peut inclure des VLAN distincts pour le management, le stockage, vMotion, la production, la DMZ et les sauvegardes. Mais la valeur réelle de cette segmentation dépend du point où les flux inter-VLAN sont routés et filtrés.

Port groups et VLAN : principes opérationnels

Un port group ne doit pas être considéré comme une zone de sécurité complète. Il représente une association entre des ports virtuels, des politiques vSwitch et éventuellement un VLAN. La sécurité dépend aussi :

• Des ACL et règles de pare-feu sur le routeur inter-VLAN.
• Du contrôle des trunks sur les commutateurs physiques.
• Des paramètres de sécurité du port group.
• De l’accès à vCenter et aux privilèges de modification réseau.
• De l’absence de VM pouvant faire office de pont involontaire entre réseaux.

Évitez autant que possible les port groups configurés en VLAN 4095, c’est-à-dire en mode trunk invité, sauf besoin précis. Cette configuration permet à une VM de recevoir plusieurs VLAN tagués et augmente le risque de mauvaise configuration ou de contournement de segmentation. Elle est adaptée à certains appliances réseau virtualisés, mais doit être limitée à ces usages.

Paramètres de sécurité à contrôler

Sur les port groups, les options suivantes méritent une vérification explicite :

• Promiscuous mode : désactivé sauf besoin documenté de capture ou d’appliance particulière.
• MAC address changes : refusé par défaut, avec exceptions justifiées.
• Forged transmits : refusé par défaut, sauf cas spécifiques comme certains mécanismes de haute disponibilité réseau.
• MAC learning : à activer uniquement lorsque nécessaire, par exemple pour certaines appliances ou conteneurs.
• VLAN trunking : limité aux appliances qui en ont réellement besoin.

Une règle utile est de traiter toute exception comme un changement de sécurité : propriétaire identifié, justification, date de revue et procédure de retour arrière.

Micro-segmentation avec VMware NSX

Les VLAN organisent principalement la segmentation au niveau L2 et L3. Ils restent efficaces pour séparer des zones, mais deviennent difficilement exploitables lorsque les applications sont nombreuses, mobiles ou réparties entre plusieurs sous-réseaux. La micro-segmentation répond à ce besoin en appliquant des politiques proches des charges de travail.

Avec VMware NSX, le firewall distribué, ou Distributed Firewall, est appliqué au niveau des interfaces virtuelles des VM. Les règles suivent donc la charge de travail, y compris lors d’un vMotion. Le filtrage ne dépend plus exclusivement du passage par un pare-feu central pour chaque flux Est-Ouest.

Firewall distribué : filtrer les flux Est-Ouest

Le principal intérêt du firewall distribué est de contrôler les communications latérales entre VM. Par exemple, un serveur web peut joindre uniquement les serveurs applicatifs sur les ports nécessaires, et ceux-ci peuvent joindre uniquement les bases de données sur les ports explicitement autorisés.

Sans micro-segmentation, deux VM placées dans le même VLAN communiquent souvent directement au niveau L2. Pour inspecter ou filtrer ce trafic, il faut le faire remonter à travers un équipement physique ou virtuel central, ce qui complique le design et peut créer des goulots d’étranglement.

Avec NSX, une politique peut s’appuyer sur plusieurs critères :

• Groupe dynamique basé sur les tags VM.
• Nom de VM, système d’exploitation ou attributs d’inventaire.
• Sous-réseau ou adresse IP.
• Port group ou segment NSX.
• Identité ou catégories applicatives, selon le niveau d’intégration.

Une approche robuste consiste à utiliser les tags comme élément de classification stable. Par exemple : app=web, app=api, app=db, env=prod, env=preprod, tier=frontend. Les groupes NSX sont alors calculés dynamiquement à partir de ces attributs.

Politique par défaut et ordre des règles

Le danger classique de la micro-segmentation est d’écrire des règles permissives trop larges, puis de se retrouver avec une solution complexe qui n’apporte pas davantage de sécurité qu’un VLAN unique. Pour aller plus loin, consultez l’intégration réseau dans un homelab.

Commencez par une stratégie progressive :

1. Observer les flux avec les outils de visibilité disponibles.
2. Créer des groupes cohérents et peu nombreux.
3. Appliquer les règles en mode journalisation ou avec une portée limitée.
4. Autoriser explicitement les dépendances applicatives identifiées.
5. Passer progressivement vers un refus par défaut entre tiers applicatifs.
6. Maintenir des règles distinctes pour l’infrastructure, les sauvegardes et la supervision.

L’ordre est déterminant. Les règles d’exception urgentes ont tendance à s’accumuler et à masquer des règles plus strictes. Révisez régulièrement les règles inutilisées, les groupes vides et les règles trop générales.

Ne pas confondre micro-segmentation et pare-feu périmétrique

Le firewall distribué est excellent pour les flux Est-Ouest, mais il ne remplace pas nécessairement un pare-feu Nord-Sud. Les flux entrant depuis Internet, les VPN, les traductions d’adresses, l’inspection périmétrique et le routage entre zones restent souvent gérés par une passerelle de sécurité dédiée, physique ou virtuelle.

L’architecture saine combine généralement :

• Pare-feu périmétrique pour les flux Nord-Sud.
• Routage et filtrage inter-VLAN pour les zones réseau.
• Firewall distribué NSX pour les flux Est-Ouest entre workloads.
• ACL physiques pour protéger les plans d’administration et d’infrastructure.

pfSense virtualisé : utile, mais pas comme unique point de survie

pfSense est couramment utilisé comme pare-feu et routeur virtualisé dans les homelabs, les environnements de test et certaines petites infrastructures. Il fournit le routage inter-VLAN, le NAT, les règles de filtrage, les VPN, le DHCP, le DNS Resolver et diverses fonctions de diagnostic. Le guide de démarrage officiel pfSense détaille les options de déploiement et les étapes d’installation initiales.

Dans un homelab, il est souvent raisonnable de déployer pfSense comme VM, à condition de comprendre le problème de démarrage circulaire : si l’hyperviseur dépend de la VM pfSense pour être administré, et que pfSense ne démarre pas ou que le datastore est indisponible, l’accès au cluster peut devenir difficile.

Architecture recommandée pour un petit environnement

Une approche pragmatique est la suivante :

• Une interface WAN dédiée ou un port group WAN isolé.
• Une interface LAN ou trunk VLAN vers le commutateur physique.
• Des interfaces ou sous-interfaces VLAN pour les zones internes.
• Un port group de management qui reste accessible par un chemin indépendant.
• Une IP de management statique sur les hôtes ESXi.
• Une console hors bande ou physique disponible en cas de panne.

Pour un pare-feu virtualisé transportant plusieurs VLAN, un trunk peut être présenté à la VM pfSense. Dans ce cas, le port group ESXi doit être configuré pour transporter les VLAN nécessaires, et la VM doit gérer le tagging 802.1Q. Limitez strictement ce privilège aux appliances réseau concernées.

Haute disponibilité pfSense

pfSense peut être déployé en paire avec synchronisation de configuration et bascule d’état via CARP, sous réserve que le réseau virtuel et physique supporte correctement les adresses MAC virtuelles et les annonces associées.

Points d’attention :

• Prévoir au moins deux nœuds physiques distincts si la disponibilité est réellement recherchée.
• Éviter de placer les deux VM pare-feu sur le même hôte ESXi.
• Utiliser des règles DRS d’anti-affinité.
• Vérifier les réglages de sécurité vSwitch concernant les MAC et les transmissions forgées.
• Tester le basculement sous charge, pas seulement le statut CARP.
• Éviter qu’un seul datastore, switch physique ou onduleur annule le bénéfice de la paire.

Pour un homelab, la simplicité peut avoir plus de valeur qu’une fausse haute disponibilité. Une seule VM pfSense bien sauvegardée, avec un export de configuration et un accès console, est parfois préférable à un cluster mal maîtrisé.

Load balancing et haute disponibilité des liens réseau

La disponibilité réseau ne dépend pas uniquement du nombre de vmnic. Il faut aligner le teaming virtuel, les agrégations physiques, les chemins de stockage et les mécanismes de bascule sur le comportement réel des commutateurs.

Sur ESXi, les politiques de répartition les plus courantes sont :

• Route based on originating virtual port : simple et compatible avec la plupart des infrastructures.
• Route based on IP hash : nécessite généralement une agrégation statique ou EtherChannel côté physique.
• Route based on physical NIC load : disponible avec vDS, ajuste dynamiquement la répartition selon la charge.
• LACP : disponible via vDS, à utiliser lorsque l’infrastructure physique est conçue pour cela.

Choisir la bonne politique de teaming

Le mode basé sur le port virtuel d’origine est souvent suffisant. Il répartit les VM ou interfaces virtuelles entre les uplinks sans nécessiter de configuration complexe sur les commutateurs. Il ne permet pas à un flux unique de dépasser la capacité d’un lien, mais cette limitation est généralement acceptable pour les flux applicatifs classiques.

L’IP hash peut sembler attractif, mais il impose une cohérence stricte avec le switch physique. Une configuration partielle provoque facilement des pertes de paquets intermittentes et des comportements difficiles à diagnostiquer. Ne l’utilisez pas simplement pour “faire du load balancing”.

LACP doit être choisi pour une raison claire : standardisation, agrégation gérée centralement, besoins de débit agrégé ou architecture de switch adaptée. Il ne résout pas automatiquement les limites d’un flux unique et ajoute une couche de diagnostic supplémentaire.

Détection de panne et chemins physiques

La détection d’échec doit couvrir les scénarios réalistes :

• Perte du lien physique.
• Perte d’un switch amont.
• Erreur de trunk ou VLAN absent.
• Perte de connectivité vers la passerelle.
• Boucle ou congestion sévère.

La détection basée uniquement sur l’état du lien ne voit pas toujours la panne d’un switch ou d’un VLAN. Selon le contexte, le beacon probing ou des mécanismes de surveillance amont peuvent compléter le contrôle, mais ils doivent être configurés avec prudence.

Pour les réseaux de stockage, évitez de mélanger sans réflexion les politiques de teaming applicatives et les recommandations du protocole utilisé. iSCSI avec port binding, par exemple, implique des contraintes spécifiques sur les vmkernel et les uplinks actifs/standby.

Sécuriser le réseau de management

Le réseau de management est la zone la plus sensible de l’infrastructure. Une compromission de vCenter, d’un hôte ESXi ou de l’administration hors bande donne souvent un contrôle étendu sur les workloads, les disques virtuels, les snapshots et les identifiants stockés. Pour aller plus loin, consultez le stockage virtualisé.

La première mesure consiste à placer le management dans un VLAN ou sous-réseau dédié, non routable directement depuis les réseaux utilisateurs, les invités ou la DMZ. L’accès doit passer par des postes d’administration maîtrisés ou, idéalement, par un bastion. Pour aller plus loin, consultez l’architecture vSphere et vCenter.

Contrôles d’accès et services d’administration

Appliquez les principes suivants :

• Autoriser l’accès à vCenter, ESXi, BMC et équipements réseau depuis des sources d’administration définies.
• Utiliser une authentification forte, idéalement avec MFA lorsque le produit et l’architecture le permettent.
• Intégrer les comptes d’administration à un annuaire avec rôles séparés.
• Désactiver les comptes locaux inutiles et protéger les comptes de secours.
• Limiter l’accès SSH et ESXi Shell aux opérations de maintenance.
• Désactiver les services non utilisés sur les hôtes.
• Centraliser les journaux vers une destination protégée.
• Synchroniser le temps avec une source NTP fiable.

Le bastion doit lui-même être traité comme un actif critique : correctifs, journalisation, contrôle des sessions, accès restreint et séparation des privilèges.

Réduire la surface d’attaque L2

La protection du management ne s’arrête pas au routage. Sur les commutateurs physiques, restreignez les VLAN autorisés sur chaque trunk, désactivez les ports inutilisés et appliquez les protections disponibles contre les attaques de couche 2.

Les bonnes pratiques incluent :

• Ne pas utiliser le VLAN natif par défaut pour le management.
• Éviter le VLAN 1 pour les services sensibles.
• Restreindre les VLAN autorisés sur les trunks ESXi.
• Configurer explicitement le VLAN natif ou le désactiver selon la politique du constructeur.
• Surveiller les changements de MAC et les événements de trunk.
• Isoler l’administration hors bande dans un réseau distinct.
• Ne pas exposer les interfaces BMC sur le réseau de production.

Exploitation, supervision et procédures de reprise

Un réseau virtuel robuste est un réseau observable. Sans visibilité, les incidents se transforment en hypothèses : est-ce le vSwitch, le VLAN, le trunk, le pare-feu, le DNS, l’uplink, le stockage ou la VM elle-même ?

Centralisez les journaux de vCenter, ESXi, pare-feu, commutateurs et NSX. Surveillez les erreurs d’interface, les changements de topologie, la saturation des uplinks, la latence réseau et les abandons de paquets. Pour les environnements NSX, exploitez les journaux de règles et les outils de traçabilité de flux avant de modifier en urgence les politiques de sécurité.

Tests à intégrer aux procédures

Les tests suivants doivent être exécutés périodiquement :

• Perte d’un uplink sur un hôte.
• Perte d’un switch d’accès ou d’une paire de liens.
• Basculement d’un pare-feu virtualisé en haute disponibilité.
• Migration vMotion avec contrôle de connectivité applicative.
• Restauration de la configuration d’un pare-feu.
• Vérification de l’accès hors bande aux hôtes.
• Validation des règles de management depuis un poste autorisé et un poste non autorisé.
• Test de restauration de vCenter ou de l’appliance de gestion réseau.

Documentez également les actions de récupération rapide : reconfigurer un vmnic depuis la console ESXi, recréer temporairement un port group de secours, restaurer une configuration pfSense, ou reconnecter une interface VMkernel au bon uplink.

Architecture de référence : progression par niveaux

Il n’est pas nécessaire de déployer immédiatement un vDS, NSX et une paire de pare-feu hautement disponible. L’architecture doit correspondre à la taille du cluster, aux compétences de l’équipe et au niveau de risque accepté.

Pour un homelab ou un petit cluster, un vSS avec VLAN clairement séparés, pfSense bien sauvegardé et une console hors bande fournit déjà une base saine. Pour une infrastructure de production multi-hôtes, un vDS apporte une cohérence opérationnelle importante et réduit les divergences de configuration. Pour des applications critiques, multi-tiers ou fortement réglementées, NSX permet de contrôler les flux Est-Ouest avec une granularité difficile à atteindre avec les seuls VLAN.

Le point commun à tous les niveaux reste le même : séparer les plans de trafic, limiter les privilèges réseau, documenter les dépendances et tester les pannes. La virtualisation ne simplifie pas automatiquement le réseau ; elle déplace une partie de sa complexité dans le logiciel. Bien maîtrisée, cette complexité apporte en revanche une meilleure cohérence, une meilleure sécurité et une capacité de reprise supérieure.