Le firewall de Proxmox peut s’appliquer au niveau du Datacenter, du nœud et de chaque VM ou conteneur. Cette organisation permet un filtrage précis, mais aussi de perdre complètement l’accès à l’interface web et à SSH si une politique DROP est activée au mauvais endroit.
Le piège de la politique DROP globale
Activer le firewall au niveau du Datacenter avec une politique d’entrée DROP peut bloquer l’administration du nœud si aucune règle n’autorise votre poste ou votre réseau.
Un redémarrage ne corrigera pas forcément le problème : le firewall peut repartir automatiquement avec exactement la même configuration. Comme l’interface web et SSH sont désormais inaccessibles, le dépannage à distance est terminé. Vous êtes officiellement bon pour aller chercher un écran et un clavier, les transporter jusqu’au serveur et vous connecter directement à la console locale. C’est généralement à cet instant précis que l’on comprend pourquoi il fallait tester les règles avant d’activer la politique DROP.
Récupérer l’accès depuis la console
Une fois devant le serveur, connectez-vous en root, puis désactivez le firewall dans la configuration du Datacenter :
pvesh set /cluster/firewall/options --enable 0
pve-firewall stop
systemctl stop pve-firewall proxmox-firewall
Si vous devez redémarrer le serveur avant de pouvoir tester son accès réseau, empêchez temporairement les services de repartir :
systemctl disable --now pve-firewall proxmox-firewall
systemctl mask pve-firewall proxmox-firewall
reboot
Pour vérifier que le firewall est bien désactivé dans la configuration Proxmox :
pvesh get /cluster/firewall/options --output-format yaml | grep enable
Le résultat attendu est :
enable: 0
Repartir sur une base sans risque
Lorsque l’interface web est de nouveau accessible, rendez-vous dans Datacenter > Firewall > Options et configurez :
Firewall: No
Input Policy: ACCEPT
Output Policy: ACCEPT
Forward Policy: ACCEPT
Dans Nœud > Firewall > Options, laissez également :
Firewall: No
L’objectif est de ne pas filtrer l’administration du nœud lorsque seule une VM ou un conteneur doit être protégé.
Limiter un LXC à une adresse précise
Dans LXC > Firewall > Add, ajoutez une règle autorisant uniquement l’adresse et le port nécessaires :
Direction: in
Action: ACCEPT
Source: ADRESSE_IP_AUTORISEE
Protocol: TCP
Dest. port: PORT_AUTORISE
Enable: Yes
Les champs Interface, Destination et Source port peuvent rester vides. Le port source du client est généralement choisi dynamiquement : ce n’est donc pas celui qu’il faut filtrer.
Dans LXC > Firewall > Options, appliquez ensuite :
Firewall: Yes
Input Policy: DROP
Output Policy: ACCEPT
Le conteneur conserve ses connexions sortantes, mais refuse les nouvelles connexions entrantes qui ne correspondent pas à une règle ACCEPT.
La case facile à oublier
Dans LXC > Network, sélectionnez l’interface réseau, généralement eth0, puis cliquez sur Edit et cochez :
Firewall: Yes
Cette étape est indispensable. Sans elle, les règles et la politique DROP du conteneur ne sont pas appliquées à son interface virtuelle.
Réactiver le moteur de firewall
Si les services ont été masqués pendant le dépannage, commencez par les démasquer :
systemctl unmask pve-firewall proxmox-firewall
systemctl enable --now pve-firewall
Activez ensuite le firewall dans Datacenter > Firewall > Options, tout en conservant les politiques globales sur ACCEPT :
Firewall: Yes
Input Policy: ACCEPT
Output Policy: ACCEPT
Forward Policy: ACCEPT
Le firewall du nœud peut rester désactivé. Le moteur fonctionne globalement, mais la politique restrictive est appliquée uniquement au LXC concerné.
Vérifier que le filtrage fonctionne
Depuis une machine qui ne figure pas dans les règles autorisées, testez le port :
nc -vz -w 3 ADRESSE_DU_LXC PORT_AUTORISE
La connexion doit expirer ou échouer. Depuis la machine autorisée, le même test doit indiquer que le port est ouvert.
Il faut effectuer les deux tests. Une connexion réussie depuis la machine autorisée prouve que le service fonctionne, mais seule une tentative refusée depuis une autre machine confirme que le firewall filtre réellement les accès.
En résumé
- Le Datacenter active le moteur avec des politiques globales
ACCEPT. - Le firewall du nœud reste désactivé.
- Le LXC utilise une politique d’entrée
DROP. - Une règle
ACCEPTautorise uniquement l’adresse et le port nécessaires. - Le firewall doit aussi être coché sur l’interface
eth0. - Le test doit être effectué depuis une machine autorisée et une machine non autorisée.
Cette méthode protège uniquement le conteneur concerné sans risquer de bloquer l’administration complète du serveur. Avant toute modification globale, gardez une console accessible. Sinon, vous savez maintenant comment se termine l’histoire : vous êtes bon pour aller trouver un écran et un clavier, puis les trimballer jusqu’au serveur pour réparer une case cochée un peu trop vite.