Le Software Defined Network (SDN) de Proxmox VE 9 transforme profondément la gestion réseau des clusters virtualisés en offrant une abstraction complète des topologies physiques. Ce guide expert détaille la configuration des zones SDN (Simple, VXLAN, EVPN, QinQ), la création de VNets (réseaux virtuels isolés définis par logiciel), la gestion IPAM intégrée pour l'allocation automatique d'adresses IP, les protocoles VXLAN et EVPN/BGP pour le routage inter-zones, ainsi que le VNet Firewall pour sécuriser vos environnements multi-tenants. Que vous administriez un homelab ou une infrastructure de production multi-nœuds, la maîtrise du SDN Proxmox est indispensable pour isoler les workloads, optimiser le routage et garantir la sécurité réseau. Ce guide couvre chaque composant avec des exemples CLI et GUI concrets, des cas d'usage réels et les meilleures pratiques pour déployer un SDN robuste et scalable sur Proxmox VE 9.

  • Identification des vecteurs d'attaque et de la surface d'exposition
  • Stratégies de détection et de réponse aux incidents
  • Recommandations de durcissement et bonnes pratiques opérationnelles
  • Impact sur la conformité réglementaire (NIS2, DORA, RGPD)

Points clés à retenir

  • Le SDN Proxmox VE 9 repose sur une hiérarchie Zones → VNets → Subnets permettant une isolation réseau complète entre tenants et workloads.
  • Les zones VXLAN et EVPN/BGP permettent d'étendre les réseaux virtuels sur l'ensemble du cluster avec routage inter-VNets et support multi-site.
  • L'IPAM intégré (PHPipam ou NetBox) automatise l'allocation d'adresses IP et élimine les conflits dans les environnements dynamiques.
  • Le VNet Firewall applique des règles de sécurité directement au niveau du réseau virtuel, indépendamment du firewall hôte ou VM.

Architecture SDN Proxmox : Zones, VNets et Subnets

L'architecture SDN Proxmox VE 9 s'organise en trois niveaux hiérarchiques : les zones définissent le type de technologie réseau (Simple, VXLAN, EVPN, QinQ), les VNets (Virtual Networks) représentent les segments réseau isolés au sein d'une zone, et les subnets définissent les plages d'adresses IP avec passerelle et options DHCP. Cette hiérarchie permet une gestion centralisée et scalable de l'infrastructure réseau virtuelle depuis l'interface web Proxmox ou via l'API REST.

La configuration SDN est stockée dans /etc/pve/sdn/ et répliquée automatiquement sur tous les nœuds du cluster via le CGFS (Cluster File System). Après chaque modification, la commande pvesh set /cluster/sdn/vnets --apply 1 propage les changements sur l'ensemble des nœuds.

Types de Zones SDN et Cas d'Usage

Zone Simple : Isolation L2 par VLAN

La zone Simple est le type le plus basique : elle crée des ponts Linux isolés sur chaque nœud. Idéale pour les environnements homlab ou petits clusters sans exigences de routage inter-VNets. Configuration minimale via GUI : Datacenter → SDN → Zones → Add → Simple, en spécifiant le bridge physique (ex: vmbr0).

Zone VXLAN : Extension L2 Multi-Nœuds

La zone VXLAN (Virtual eXtensible Local Area Network) encapsule le trafic L2 dans des paquets UDP pour l'étendre sur le réseau IP du cluster. Chaque VNet reçoit un VNI (VXLAN Network Identifier) unique. Cette zone convient aux clusters multi-nœuds nécessitant des réseaux virtuels partagés sans routage centralisé. Prérequis : MTU ≥ 1550 sur le réseau physique pour absorber l'overhead VXLAN (50 bytes).

Zone EVPN/BGP : Routage Inter-VNets Distribué

La zone EVPN (Ethernet VPN) combine VXLAN pour le transport L2 avec BGP (Border Gateway Protocol) pour la distribution des routes L3. Elle permet le routage inter-VNets sans dépendance à un routeur centralisé, avec support de l'anycast gateway pour une redondance optimale. Configuration requise : un routeur BGP par nœud (généralement FRRouting), un ASN dédié et un VTEP IP par nœud.

Zone QinQ : Double Encapsulation VLAN

La zone QinQ (802.1ad) permet la double encapsulation VLAN (VLAN externe opérateur + VLAN interne client). Utilisée principalement dans les environnements MSP (Managed Service Provider) pour isoler les infrastructures clients tout en partageant une infrastructure physique commune.

Configuration des VNets et Subnets

Un VNet est créé via Datacenter → SDN → VNets → Add, en associant un nom, une zone parente et un tag VLAN optionnel. Pour les zones VXLAN/EVPN, un VNI est automatiquement assigné. La commande CLI équivalente :

pvesh create /cluster/sdn/vnets -vnet vnet100 -zone vxlan-zone -tag 100

Les subnets définissent les plages CIDR avec passerelle (gateway), serveur DHCP optionnel et DNS. Pour activer le DHCP sur un subnet, le service dnsmasq doit être configuré sur les nœuds Proxmox. Un subnet avec SNAT (Source NAT) permet aux VMs d'accéder à Internet sans IP publique dédiée.

IPAM Intégré : Gestion Automatique des Adresses IP

L'IPAM (IP Address Management) intégré dans Proxmox VE 9 élimine la gestion manuelle des adresses IP. Deux backends sont supportés : PHPipam (self-hosted) et NetBox (DCIM complet). La configuration s'effectue dans Datacenter → SDN → IPAM → Add en spécifiant l'URL de l'instance et le token API.

Une fois l'IPAM configuré, lors de la création d'un subnet SDN avec l'option IPAM activée, les adresses allouées aux VMs sont automatiquement enregistrées dans la base IPAM. Cela garantit une visibilité centralisée et évite les conflits d'adresses dans les environnements à forte densité de VMs.

Type de ZoneProtocoleRoutage Inter-VNetsCas d'Usage
SimpleLinux BridgeNon (L2 uniquement)Homelab, petit cluster
VXLANVXLAN/UDPNon (L2 étendu)Multi-nœuds sans routage
EVPNVXLAN + BGPOui (L3 distribué)Production, multi-tenant
QinQ802.1adNon (double VLAN)MSP, isolation client

VNet Firewall : Sécurité au Niveau Réseau Virtuel

Le VNet Firewall de Proxmox SDN applique des règles de filtrage directement au niveau du réseau virtuel, en amont du firewall hôte et VM. Il s'appuie sur ebtables (filtrage L2) et iptables/nftables (filtrage L3/L4) pour contrôler le trafic entrant et sortant de chaque VNet.

Les règles sont définies dans Datacenter → SDN → VNets → [VNet] → Firewall et s'appliquent à toutes les VMs connectées à ce VNet. Les IPSets permettent de regrouper des plages d'adresses pour simplifier la gestion des règles. La politique par défaut (DROP ou ACCEPT) est configurable par VNet.

Pour sécuriser un environnement multi-tenant, la bonne pratique consiste à créer une zone EVPN par tenant avec VNet Firewall activé en mode DROP par défaut, n'autorisant que les flux explicitement listés. Consultez notre guide de hardening Proxmox VE pour une stratégie de sécurité complète.

Déploiement EVPN : Configuration FRRouting et BGP

FRRouting (FRR) est le daemon de routage utilisé par Proxmox pour implémenter EVPN. Il est installé automatiquement avec le plugin EVPN SDN. La configuration BGP générée dans /etc/frr/frr.conf définit les sessions iBGP entre les nœuds du cluster, les VNIs à redistribuer et les anycast gateways.

Exemple de vérification de l'état BGP : vtysh -c "show bgp summary". Pour diagnostiquer les routes EVPN : vtysh -c "show bgp l2vpn evpn". En cas de problème de routage inter-VNets, vérifier que le ip_forward est activé sur tous les nœuds et que les VNIs sont cohérents entre les zones.

Dépannage SDN et Commandes Clés

Le diagnostic SDN Proxmox repose sur plusieurs outils : pvesh get /cluster/sdn/vnets liste les VNets configurés, bridge fdb show affiche la table de forwarding L2, et ip route show table [VNI] vérifie les routes EVPN injectées. Les logs SDN se trouvent dans /var/log/pve/tasks/ après chaque apply.

Pour les problèmes de connectivité VXLAN, vérifier les règles firewall sur le port UDP 4789 (VXLAN) avec iptables -L -n | grep 4789. Pour EVPN, s'assurer que le port TCP 179 (BGP) est ouvert entre les nœuds. La documentation officielle Proxmox SDN et le wiki Proxmox sont des références indispensables.

Pour aller plus loin sur l'architecture réseau, consultez notre guide d'architecture cluster Proxmox 3 nœuds et notre référence CLI d'administration Proxmox.

Questions fréquentes

Comment choisir entre une zone VXLAN et une zone EVPN dans Proxmox SDN ?

La zone VXLAN est recommandée lorsque vous avez uniquement besoin d'étendre des réseaux L2 entre nœuds sans routage inter-VNets. Elle est plus simple à configurer et consomme moins de ressources. La zone EVPN s'impose dès que vous avez besoin de routage L3 distribué entre VNets, de support anycast gateway pour la redondance ou d'une architecture multi-site. En production avec plusieurs tenants isolés nécessitant des politiques de routage distinctes, EVPN est le choix incontournable.

Pourquoi l'IPAM SDN Proxmox est-il préférable à une gestion manuelle des IPs ?

Dans un cluster Proxmox avec des dizaines ou centaines de VMs, la gestion manuelle des adresses IP génère inévitablement des conflits et des erreurs. L'IPAM intégré (PHPipam ou NetBox) automatise l'allocation, garantit l'unicité des adresses et offre une visibilité centralisée de toute la plage réseau. Il s'intègre directement avec les subnets SDN pour enregistrer automatiquement chaque VM créée, éliminant le travail de documentation manuelle et réduisant les incidents réseau liés aux conflits d'IP.

Comment sécuriser les communications entre VNets dans un environnement multi-tenant Proxmox ?

La sécurité multi-tenant repose sur l'isolation stricte des zones SDN avec VNet Firewall activé en politique DROP par défaut. Chaque tenant dispose de sa propre zone EVPN avec VNIs dédiés, empêchant toute communication non autorisée. Le VNet Firewall applique des règles ebtables/iptables au niveau du bridge virtuel, avant même que le trafic n'atteigne le firewall de la VM. Les IPSets permettent de définir des listes blanches précises. Pour le trafic inter-tenants légitimes, des VRFs (Virtual Routing and Forwarding) dédiés dans FRRouting assurent l'isolation des tables de routage.

Sources et références : Proxmox VE Wiki · ANSSI

Conclusion

Le SDN Proxmox VE 9 offre une architecture réseau virtualisée puissante et flexible, de la simple isolation VLAN aux topologies EVPN/BGP multi-sites. La maîtrise des zones SDN, de l'IPAM intégré et du VNet Firewall permet de construire des infrastructures multi-tenants robustes, sécurisées et automatisables. L'investissement dans la compréhension de ces concepts se traduit directement par une réduction des incidents réseau et une agilité accrue dans la gestion des workloads.

Article suivant recommandé

Architecture Proxmox VE 9.1 : Cluster 3 Nœuds + HA →

Découvrez mon outil

proxmox-cluster-manager

Gestionnaire de cluster Proxmox VE

Voir →

Surface d'attaque : Ensemble des points d'entrée exploitables par un attaquant pour compromettre un système, incluant les services exposés, les interfaces utilisateur et les API.

Snapshotez systématiquement vos machines virtuelles avant toute modification critique. Un snapshot prend quelques secondes et peut éviter des heures de reconstruction.

Ayi NEDJIMI

Sécurisez votre infrastructure virtualisée

Audit Proxmox, VMware, Hyper-V — durcissement hyperviseur, segmentation, protection anti-ransomware.

Configuration Avancée des Zones SDN Proxmox VE 9 : Simple et VXLAN

Le module SDN (Software Defined Networking) de Proxmox VE 9 permet de définir des topologies réseau virtuelles complexes directement depuis l'interface de gestion du cluster, sans nécessiter de configuration manuelle sur chaque noeud. Les zones SDN constituent la brique de base de cette architecture, définissant le type de réseau virtuel et ses paramètres de connectivité. Proxmox VE 9 supporte plusieurs types de zones adaptés à différents scénarios de déploiement.

Les trois types de zones SDN principaux dans Proxmox VE 9 :

  • Zone Simple : réseau L2 local au noeud Proxmox, non partagé entre les noeuds du cluster, adapté aux tests et aux VMs isolées sans besoin de migration live entre noeuds. Simple à configurer mais limité à un seul noeud physique.
  • Zone VLAN : étend les VLANs 802.1Q existants sur le réseau physique sous-jacent au niveau SDN, permettant l'isolation L2 des VMs selon leur VLAN d'appartenance sur les switchs physiques supportant les troncal 802.1Q. Nécessite une configuration correspondante sur les switchs physiques.
  • Zone VXLAN : crée des tunnels L2 over L3 entre les noeuds du cluster via UDP (port 4789 par défaut), permettant d'étendre des réseaux L2 entre noeuds physiquement distants sans nécessiter de configuration sur les switchs intermédiaires. Adapté aux clusters multi-sites et aux datacenters avec des réseaux physiques distincts.
  • Zone EVPN : niveau le plus avancé, combinant VXLAN pour le transport avec BGP EVPN pour la distribution automatique des informations de routage MAC/IP entre les noeuds, éliminant le besoin de flooding L2 et scalant mieux pour les grands déploiements avec de nombreux VNets

La configuration d'une zone VXLAN simple entre deux noeuds Proxmox VE 9 :

pvesh create /cluster/sdn/zones   --zone vxlan-prod   --type vxlan   --peers 192.168.1.10,192.168.1.11   --mtu 1450
pvesh create /cluster/sdn/vnets   --vnet vnet-webapp   --zone vxlan-prod   --tag 1001
pvesh set /cluster/sdn
# Appliquer la configuration sur tous les noeuds
pvesh create /nodes/{node}/sdn/apply

IPAM et Firewall Distribué dans Proxmox VE 9 SDN

L'IPAM (IP Address Management) intégré au module SDN de Proxmox VE 9 permet de gérer automatiquement l'allocation des adresses IP pour les VMs et conteneurs connectés aux VNets SDN, évitant les conflits d'adressage et offrant une visibilité centralisée sur l'utilisation du plan d'adressage. Proxmox VE 9 propose un IPAM interne simple stocké dans la configuration du cluster, ainsi que des connecteurs vers des solutions IPAM externes comme NetBox ou phpIPAM pour les organisations disposant déjà d'un outil de gestion d'adressage IP.

La configuration d'un sous-réseau IPAM dans Proxmox VE 9 :

pvesh create /cluster/sdn/ipams   --ipam netbox   --url https://netbox.company.com   --token "Token xxxxxxxxxxxx"
pvesh create /cluster/sdn/vnets/vnet-webapp/subnets   --subnet 10.20.30.0/24   --gateway 10.20.30.1   --ipam netbox   --dhcp-range start-address=10.20.30.100,end-address=10.20.30.200
  • DHCP automatique : les VMs connectées à un VNet SDN avec IPAM et plage DHCP configurée reçoivent automatiquement une adresse IP, enregistrée dans l'IPAM, sans intervention manuelle sur chaque VM
  • Réservation d'adresses statiques : des adresses IP statiques peuvent être réservées pour des VMs spécifiques via leur adresse MAC dans l'IPAM, garantissant une adresse fixe sans configuration manuelle dans le système d'exploitation de la VM
  • Reverse DNS automatique : l'IPAM peut automatiquement créer les enregistrements DNS reverse (PTR) dans un serveur DNS interne, facilitant la résolution d'adresses IP vers des noms d'hôtes pour les équipes de monitoring et de sécurité

Le firewall distribué de Proxmox VE 9 SDN permet d'appliquer des règles de filtrage L3/L4 directement au niveau du VNet, indépendamment du système d'exploitation des VMs et des règles de firewall de chaque VM individuelle. Ces règles sont appliquées au niveau de la couche virtuelle de l'hyperviseur, ce qui signifie qu'elles ne peuvent pas être contournées par un système d'exploitation de VM compromis qui aurait désactivé son propre firewall. La combinaison du firewall distribué SDN avec les Network Policies Kubernetes (pour les clusters K8s hébergés sur Proxmox) et les règles de firewall individuelles des VMs constitue une défense en profondeur réseau complète pour les environnements de virtualisation Proxmox VE 9 en production.

La surveillance du trafic SDN s'effectue via les statistiques de flux disponibles dans l'interface Proxmox et via l'intégration avec des outils de monitoring réseau comme Prometheus avec l'exporter proxmox-pve-exporter, permettant de visualiser les volumes de trafic par VNet, de détecter les anomalies de flux et d'identifier les VMs générant un trafic inhabituel pouvant indiquer une compromission ou une mauvaise configuration applicative affectant les performances du réseau virtuel.

Haute Disponibilité du Réseau SDN dans les Clusters Proxmox VE 9

La haute disponibilité du réseau SDN dans un cluster Proxmox VE 9 multi-noeuds nécessite une attention particulière à la configuration des liaisons physiques sous-jacentes et des mécanismes de redondance. Un réseau SDN bien conçu doit tolérer la perte d'un noeud ou d'une liaison réseau sans interruption du service pour les VMs hébergées, en assurant la continuité du plan de contrôle SDN et la disponibilité des VNets sur les noeuds survivants.

Les mécanismes de redondance réseau recommandés pour les déploiements Proxmox VE 9 en production :

  • LACP (Link Aggregation Control Protocol) / Bond : agréger deux ou quatre ports réseau physiques en une liaison logique unique qui combine la bande passante et offre une tolérance à la panne d'un port individuel, configuré via Linux bonding avec le mode 802.3ad en coordination avec des switchs supportant LACP
  • Multi-path SDN VXLAN : configurer plusieurs adresses de tunnel VTEP sur différentes interfaces physiques pour le trafic VXLAN, permettant au protocole de faire basculer le trafic SDN sur une interface de secours en cas de perte de connectivité sur l'interface principale
  • Séparation des réseaux sur des cartes distinctes : isoler le trafic de gestion Proxmox (port 8006 et corosync), le trafic de stockage Ceph ou NFS, et le trafic VM sur des cartes réseau physiques distinctes pour éviter qu'une saturation du trafic VM n'impacte la connectivité de gestion du cluster
  • Réseau de gestion OOB : utiliser les interfaces IPMI/BMC des serveurs sur un réseau de gestion hors-bande dédié pour maintenir l'accès aux noeuds même en cas de perte totale de connectivité sur les interfaces réseau de production

La surveillance de la santé du réseau SDN s'effectue via les alertes Proxmox sur l'état des liaisons réseau (link up/down), les métriques de performance des VNets disponibles dans l'interface de monitoring et via Prometheus avec l'exporter proxmox-pve-exporter. Des seuils d'alerte sur la latence des tunnels VXLAN inter-noeuds et la perte de paquets permettent de détecter une dégradation du réseau sous-jacent avant qu'elle n'impacte les performances des VMs hébergées dans les VNets SDN du cluster Proxmox VE 9.

Migration vers SDN Proxmox VE 9 depuis une Architecture Réseau Classique

La migration d'une infrastructure Proxmox existante utilisant des bridges Linux traditionnels (vmbr0, vmbr1, etc.) vers l'architecture SDN de Proxmox VE 9 représente une évolution significative qui nécessite une planification minutieuse pour éviter les interruptions de service. La migration en place (in-place migration) consiste à reconfigurer progressivement les VMs depuis les bridges traditionnels vers les VNets SDN, interface par interface, en validant la connectivité après chaque modification avant de passer à la VM suivante.

La stratégie recommandée pour une migration SDN sans interruption de service majeure commence par la création en parallèle de la nouvelle topologie SDN (zones, VNets, subnets IPAM) sans supprimer les bridges existants, puis le test de la nouvelle configuration avec des VMs non critiques avant la migration des VMs de production. Des scripts de migration automatisés peuvent être développés en Python ou Bash en utilisant l'API REST de Proxmox pour modifier les configurations réseau des VMs de façon programmatique, réduisant le risque d'erreur de configuration manuelle et permettant un rollback rapide en cas de problème détecté pendant la migration. La documentation détaillée de la topologie réseau avant et après migration dans NetBox ou un outil similaire de gestion d'infrastructure facilite le suivi des changements et la résolution des problèmes de connectivité pouvant survenir pendant les phases de migration dans les environnements de production avec de nombreuses VMs à migrer vers le nouveau modèle SDN.

Le module SDN de Proxmox VE 9 représente une évolution majeure vers une infrastructure réseau définie par logiciel qui offre plus de flexibilité, de visibilité et de contrôle sur les communications entre machines virtuelles qu'une architecture basée sur des bridges Linux statiques. Son adoption progressive dans les environnements de production, guidée par une planification rigoureuse et une validation étape par étape, transforme la gestion réseau de l'infrastructure de virtualisation en un service agile et automatisable aligné sur les pratiques modernes d'infrastructure as code.