Règles du pare-feu Proxmox non appliquées : conflits iptables vs nftables expliqués

Ce que vous déboguez vraiment (plomberie Netfilter, pas l’interface)

Les règles du pare‑feu Proxmox finissent par être installées dans le filtre de paquets du noyau Linux (Netfilter). Le service Proxmox (pve-firewall) génère des règles et les applique en utilisant les outils disponibles sur l’hôte. Si l’hôte utilise nftables et que votre réflexe de dépannage est iptables (ou inversement), vous pouvez regarder des chaînes vides pendant une heure alors que le trafic circule joyeusement.

Voici l’essentiel : « iptables » est à la fois (a) une interface en ligne de commande et (b) un format de règles hérité. Sur Debian/Proxmox modernes, la commande iptables peut être un frontend de compatibilité qui écrit des règles nftables (« iptables-nft »). Donc lorsque vous dites « montrez-moi les règles iptables », vous regardez peut‑être une vue différente de celle qui est réellement active.

Conclusion opérationnelle : quand les règles du pare‑feu « ne s’appliquent pas », vous faites généralement face à l’un de ces cas :

• Les règles sont installées dans nftables, mais vous inspectez iptables-legacy (ou l’inverse).
• Les règles sont installées mais appliquées dans un hook/une chaîne inattendue (pont vs routage ; priorités raw/mangle/filter).
• Conntrack laisse les flux existants continuer, ce qui rend votre nouvelle règle inutile en apparence.
• Un autre gestionnaire de pare‑feu (ufw, firewalld, docker, kube‑proxy, un script « utile ») réécrit les tables après que Proxmox ait appliqué ses règles.
• Différences de configuration dans le cluster : l’interface modifie un nœud, un autre nœud applique des paramètres locaux différents.

Un pare‑feu, c’est comme une réunion : la moitié du drame tient à qui a parlé en premier. (Blague 1/2.)

Faits et contexte historique intéressants (pour comprendre la bizarrerie)

1. Netfilter est dans le noyau ; iptables et nftables sont des plans de contrôle en espace utilisateur. Les deux programment finalement les mêmes hooks du noyau, mais avec des représentations et des sémantiques de règles différentes.
2. nftables a été conçu pour remplacer iptables et réduire la duplication entre tables IPv4/IPv6/ARP, en ajoutant des ensembles, des maps et une syntaxe plus propre.
3. Debian a changé l’implémentation par défaut d’iptables vers « iptables-nft ». Cela signifie que iptables peut manipuler des règles nftables à moins que vous ne choisissiez explicitement iptables-legacy.
4. iptables-legacy et nftables peuvent fonctionner en même temps sans erreurs évidentes. Ce n’est pas une fonctionnalité ; c’est une taxe de débogage.
5. Le filtrage des bridges est particulier. Les paquets traversant des bridges Linux peuvent être filtrés via br_netfilter et des sysctls comme net.bridge.bridge-nf-call-iptables, ce qui change la signification pratique de « INPUT » et « FORWARD ».
6. Le comportement par défaut de conntrack surprend. Les nouveaux drops ne tuent pas forcément les connexions établies sauf si vous bloquez ou réinitialisez explicitement ; il est souvent nécessaire de purger conntrack pour un test propre.
7. Docker a historiquement beaucoup utilisé iptables et peut insérer des règles NAT/FORWARD qui contredisent les attentes locales — particulièrement en mixant des frontends nftables.
8. L’ordre des règles et la priorité des chaînes comptent davantage dans nftables car plusieurs chaînes de base peuvent hooker la même étape avec des priorités explicites.
9. Le pare‑feu Proxmox est centré sur l’hôte mais gère aussi des règles au niveau VM ; celles‑ci peuvent être implémentées via iptables/nftables sur l’hôte, pas à l’intérieur du guest, ce qui surprend ceux qui partent du principe « le pare‑feu tourne là où tourne l’appli ».

Une idée paraphrasée que j’apprécie encore — « l’espoir n’est pas une stratégie » — est largement partagée dans la pensée opérationnelle. Traitez l’état du pare‑feu comme quelque chose que vous mesurez, pas comme quelque chose que vous ressentez.

Playbook de diagnostic rapide

Quand les règles du pare‑feu Proxmox ne s’appliquent pas, vous voulez le chemin le plus court vers le premier indice réel. Voici l’ordre qui gagne lors d’incidents réels.

1) Confirmez quel backend vous utilisez réellement (nft vs legacy)

• Si l’hôte utilise nftables (nft list ruleset montre des chaînes actives), arrêtez de regarder les sorties iptables -S du mauvais backend.
• Si les deux sont présents, décidez lequel est autoritatif et supprimez l’ambiguïté.

2) Confirmez l’état du service pve-firewall et le dernier apply

• Est‑ce que pve-firewall tourne et applique les règles sans erreurs ?
• Éditez‑vous le bon scope (Datacenter vs node vs VM) ?

3) Confirmez que les paquets empruntent le chemin que vous pensez

• Le chemin bridge vs routé change les chaînes et les hooks.
• Vérifiez les sysctls br_netfilter et que la bonne interface est filtrée.

4) Vérifiez le churn de règles par d’autres acteurs

• ufw/firewalld, docker, kube‑proxy, scripts personnalisés.
• Cherchez des horodatages dans les logs et des deltas de règles.

5) Rendez votre test valide

• Purgez conntrack (avec prudence) ou testez avec de nouvelles connexions.
• Utilisez des compteurs/logs pour prouver qu’une règle est atteinte.

Comment fonctionne le pare‑feu Proxmox en coulisses

Le pare‑feu de Proxmox n’est pas un bouclier magique contre les paquets. C’est un générateur de règles et un gestionnaire de cycle de vie. Vous déclarez l’intention dans l’interface ou dans la configuration sous /etc/pve/, et pve-firewall traduit cela en règles pour le noyau.

Les règles sont généralement appliquées sur l’hôte, affectant :

• Le trafic hôte (plan de management) : SSH, interface GUI, trafic de cluster, trafic de stockage.
• Le trafic VM et containers : selon le bridge/le routage et les réglages du pare‑feu, l’hôte filtre le trafic traversant les bridges ou les interfaces tap.

Proxmox possède aussi plusieurs périmètres :

• Pare‑feu Datacenter : règles globales de base ; utile pour des modèles « refuser par défaut ».
• Pare‑feu Node : règles spécifiques à l’hôte (pensez accès IPMI, réseaux d’administration locaux).
• Pare‑feu VM/CT : autorisations/refus par invité, utile quand des équipes partagent le même domaine L2 et que vous voulez segmenter sans réarchitecturer le réseau.

Si les règles « ne s’appliquent pas », une raison courante est simplement que le pare‑feu est activé dans un périmètre mais pas dans les autres, ou activé mais pas sur l’interface réellement utilisée par le trafic (classique avec plusieurs bridges).

iptables vs nftables : modèles de conflit qui cassent les règles Proxmox

Modèle de conflit 1 : « iptables n’affiche rien, donc il n’y a pas de règles »

Si iptables est le frontend nft, il vous montrera une vue compatible iptables des règles stockées dans nftables. Mais si vous exécutez iptables-legacy (ou que vos scripts l’appellent), vous pouvez vous retrouver avec deux réalités différentes :

• Proxmox applique des règles via nftables (directement ou via iptables-nft)
• Votre commande de debug lit les tables legacy
• Vous concluez « pas de règles », et commencez à « réparer » la mauvaise chose

Modèle de conflit 2 : nftables et iptables-legacy sont tous deux actifs

C’est le mode de défaillance le plus coûteux car il peut fonctionner à moitié. Certains trafics sont filtrés ; d’autres non. Le NAT se comporte de manière incohérente. Un reboot change le comportement selon le service qui démarre en premier.

Si vous voulez un système stable, choisissez-en un. Sur Proxmox moderne sous Debian, cela signifie généralement nftables comme mécanisme noyau, avec iptables-nft pour compatibilité si nécessaire. Mais ne laissez pas des règles iptables-legacy traîner comme de vieilles demandes de changement que personne ne veut prendre en charge.

Modèle de conflit 3 : le trafic pont n’atteint pas les chaînes que vous attendez

Dans Proxmox, le trafic VM traverse souvent des bridges Linux (vmbr0) et des dispositifs tap (tapX) ou des interfaces veth (containers). Le fait que le trafic de bridge soit évalué par iptables/nftables dépend de br_netfilter et des sysctls.

Si ces sysctls sont désactivés, votre règle « FORWARD drop » peut ne pas voir les paquets pontés. Vous jurerez que le pare‑feu est cassé ; Linux continuera poliment le bridging en L2, comme vous lui avez demandé.

Modèle de conflit 4 : conntrack vous fait penser que votre nouvelle règle n’a pas fonctionné

Vous bloquez le port 443, mais votre session curl existante continue. C’est conntrack. Beaucoup de règles acceptent ct state established,related tôt, ce qui est correct pour la performance et pour ne pas casser les sessions longues — mais cela embrouille les tests.

Modèle de conflit 5 : un autre composant réécrit les règles après Proxmox

Les suspects habituels : docker, kube‑proxy, ufw, firewalld, scripts personnalisés dans cron ou timers systemd, et certains agents d’automatisation réseau. Ils ne se préoccupent pas de votre interface. Ils se préoccupent de leur propre état désiré.

Si les règles « s’appliquent » puis se rétablissent, c’est votre premier suspect. Les outils de pare‑feu sont comme des tout‑petits : si deux d’entre eux partagent les mêmes jouets, l’un pleurera. (Blague 2/2.)

Tâches pratiques : commandes, sorties et décisions (12+)

Voici les vérifications que je lance lorsque quelqu’un dit « les règles du pare‑feu Proxmox ne s’appliquent pas ». Chacune inclut une sortie réaliste et la décision à prendre.

Task 1: Check if Proxmox firewall is enabled at all scopes

cr0x@server:~$ pve-firewall status
Status: enabled
Running: yes
Log level: info

Ce que cela signifie : Le service tourne et le pare‑feu est activé. Si vous voyez Status: disabled, arrêtez‑vous ici — activez‑le dans l’interface ou la config avant de poursuivre à la chasse aux fantômes iptables.

Décision : Si désactivé, activez et retestez. Si activé, poursuivez avec les vérifications du backend de règles.

Task 2: Confirm the pve-firewall service health and recent errors

cr0x@server:~$ systemctl status pve-firewall --no-pager
● pve-firewall.service - PVE Firewall
     Loaded: loaded (/lib/systemd/system/pve-firewall.service; enabled)
     Active: active (running) since Thu 2025-12-26 10:12:33 UTC; 2h 8min ago
   Main PID: 1321 (pve-firewall)
      Tasks: 1 (limit: 154850)
     Memory: 21.4M
        CPU: 4.102s

Ce que cela signifie : Si cela affiche « failed » ou des redémarrages rapides, vos règles peuvent ne pas être appliquées ou ne l’être que partiellement.

Décision : Si en échec, inspectez les logs ensuite et corrigez les erreurs de service/runtime avant de plonger dans nftables.

Task 3: Read pve-firewall logs for rule-apply failures

cr0x@server:~$ journalctl -u pve-firewall -n 60 --no-pager
Dec 26 10:12:33 server pve-firewall[1321]: starting PVE firewall
Dec 26 10:12:34 server pve-firewall[1321]: status update OK
Dec 26 10:12:35 server pve-firewall[1321]: ruleset applied

Ce que cela signifie : « ruleset applied » est votre point de référence. Des erreurs du type « iptables-restore failed » ou « nft: syntax error » restreignent immédiatement la recherche au tooling/backend.

Décision : Si vous voyez des erreurs de restore/apply, vérifiez le backend iptables/nftables et la syntaxe des règles ensuite.

Task 4: Determine whether iptables is using nft backend or legacy backend

cr0x@server:~$ update-alternatives --display iptables
iptables - auto mode
  link best version is /usr/sbin/iptables-nft
  link currently points to /usr/sbin/iptables-nft
  link iptables is /usr/sbin/iptables
/usr/sbin/iptables-legacy - priority 10
/usr/sbin/iptables-nft - priority 20

Ce que cela signifie : Le iptables de cet hôte programme nftables. Si vos scripts appellent explicitement iptables-legacy, vous risquez un split‑brain du pare‑feu.

Décision : Standardisez : choisissez iptables-nft (commun sur Debian/Proxmox) sauf raison forte contraire.

Task 5: Inspect nftables ruleset (the real source of truth on nft hosts)

cr0x@server:~$ nft list ruleset | sed -n '1,80p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy accept;
    ct state established,related accept
    iifname "lo" accept
  }
  chain forward {
    type filter hook forward priority 0; policy accept;
  }
}

Ce que cela signifie : Vous avez une table inet filter minimale avec un accept par défaut. Si le pare‑feu Proxmox est « activé » mais que vous ne voyez pas de chaînes/tables générées par Proxmox, soit il n’applique pas à nftables, soit un autre outil a effacé son travail.

Décision : Si les règles Proxmox manquent, confirmez si Proxmox est configuré pour utiliser nftables/iptables correctement et si un service concurrent remplace les rulesets.

Task 6: Inspect iptables rules (but ensure you know which backend you’re seeing)

cr0x@server:~$ iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

Ce que cela signifie : Cela ne vous dit presque rien seul. Sur iptables-nft, c’est une vue de compatibilité. Si c’est vide tandis que nft montre des règles, vous mélangez probablement des outils ou regardez la mauvaise famille de tables.

Décision : Utilisez nft pour une inspection autoritative si votre iptables est adossé à nft. N’utilisez iptables-legacy que si vous avez délibérément standardisé sur legacy (rare et de plus en plus pénible).

Task 7: Check whether iptables-legacy is also populated (split brain detection)

cr0x@server:~$ iptables-legacy -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N PVEFW-INPUT
-A INPUT -j PVEFW-INPUT

Ce que cela signifie : Si legacy montre des chaînes Proxmox mais nft ne le fait pas, ou inversement, vous avez un décalage de backend. Le trafic suivra les règles actives du noyau, pas votre récit préféré.

Décision : Alignez les alternatives et réappliquez les règles Proxmox. Supprimez les règles de l’autre backend pour éviter la confusion.

Task 8: Confirm kernel modules and sysctls for bridge filtering

cr0x@server:~$ lsmod | grep br_netfilter || true
br_netfilter           32768  0
bridge                311296  1 br_netfilter

cr0x@server:~$ sysctl net.bridge.bridge-nf-call-iptables net.bridge.bridge-nf-call-ip6tables
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1

Ce que cela signifie : Les paquets pontés traverseront les hooks netfilter, permettant à votre pare‑feu hôte de filtrer le trafic VM sur les bridges.

Décision : Si ces valeurs sont 0, le trafic ponté peut contourner les hooks attendus. Décidez si vous voulez activer le filtrage des bridges (courant pour le firewalling VM Proxmox) et configurez‑le de façon persistante si nécessaire.

Task 9: Confirm which interfaces and bridges carry the traffic

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
eno1             UP             3c:ec:ef:11:22:33
vmbr0            UP             3c:ec:ef:11:22:33
tap100i0         UP             fe:1a:2b:3c:4d:5e

Ce que cela signifie : Si votre règle est appliquée à vmbr1 mais que le trafic circule via vmbr0, votre règle « ne fait rien » car elle ne voit jamais les paquets.

Décision : Cartographiez le chemin du service : client → NIC physique → bridge → tap/veth → guest. Filtrez au bon périmètre.

Task 10: Use counters to prove a rule is (or isn’t) being hit (nft)

cr0x@server:~$ nft -a list chain inet filter input
table inet filter {
  chain input { # handle 1
    type filter hook input priority 0; policy accept;
    ct state established,related accept # handle 2
    iifname "lo" accept # handle 3
  }
}

Ce que cela signifie : Si des règles générées par Proxmox existaient, vous les verriez ici, idéalement avec des compteurs. Aucun compteur signifie que vous ne regardez pas la bonne chaîne/table ou que les règles ne sont pas installées.

Décision : Si vous ne trouvez pas la règle, arrêtez de tester le trafic et commencez à trouver qui possède le ruleset.

Task 11: Monitor rule churn in real time (catch the culprit)

cr0x@server:~$ watch -n 1 'nft list ruleset | sha256sum | cut -d" " -f1'
3b26b25bbf6b613c6b6be8e5d2f1c8d0f50e3b0c6c1b86e3e9c6a2d4b9c7e012

Ce que cela signifie : Si le hash change toutes les quelques secondes ou juste après que vous appliquiez les règles Proxmox, quelque chose réécrit le ruleset.

Décision : Identifiez et désactivez le gestionnaire en conflit, ou intégrez‑le correctement. « Deux contrôleurs » n’est pas un pattern de conception.

Task 12: Identify other firewall managers and rule writers

cr0x@server:~$ systemctl list-unit-files | egrep 'ufw|firewalld|nftables|docker|kube|netfilter' || true
docker.service                         enabled
nftables.service                       enabled
pve-firewall.service                   enabled

Ce que cela signifie : Si nftables.service est activé et charge son propre /etc/nftables.conf, il peut remplacer l’état désiré de Proxmox, selon l’ordre de démarrage et la configuration.

Décision : Laissez Proxmox être le propriétaire (commun sur les hôtes PVE) ou assurez‑vous que le service nftables est compatible et ne vide/remplace pas les tables dont Proxmox dépend.

Task 13: Check whether nftables service flushes rules on reload

cr0x@server:~$ sed -n '1,120p' /etc/nftables.conf
#!/usr/sbin/nft -f

flush ruleset

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
  }
}

Ce que cela signifie : flush ruleset est une purge complète. Si cela s’exécute après pve-firewall, vos règles Proxmox « ne s’appliquent pas » parce qu’elles sont supprimées.

Décision : Retirez la purge complète, ou désactivez nftables.service, ou intégrez explicitement les tables gérées par Proxmox. Ne lancez pas deux configs « autoritaires » en concurrence.

Task 14: Confirm Proxmox cluster filesystem config matches expectation

cr0x@server:~$ grep -R "enable:" -n /etc/pve/firewall | head
/etc/pve/firewall/cluster.fw:2:enable: 1
/etc/pve/firewall/server.fw:2:enable: 1

Ce que cela signifie : Les drapeaux d’activation du pare‑feu sont stockés dans la config du cluster. Mais des particularités locales du nœud (alternatives, services, sysctls) peuvent encore différer et provoquer une application incohérente.

Décision : Si un seul nœud se comporte mal, comparez la sélection du backend et les autres services sur ce nœud en premier, pas la config GUI.

Task 15: Check conntrack for “rule seems ignored” situations

cr0x@server:~$ conntrack -L 2>/dev/null | head
tcp      6 431999 ESTABLISHED src=10.10.10.50 dst=10.10.10.21 sport=51522 dport=443 src=10.10.10.21 dst=10.10.10.50 sport=443 dport=51522 [ASSURED] mark=0 use=1

Ce que cela signifie : Les flux établis peuvent continuer à passer si vos règles acceptent les connexions établies tôt (commun et correct).

Décision : Pour les tests, ouvrez une toute nouvelle connexion depuis un autre port source ou purgez conntrack pour des tuples spécifiques (plus chirurgical que de tout supprimer).

Task 16: Flush a specific conntrack flow (surgical test)

cr0x@server:~$ conntrack -D -p tcp --orig-src 10.10.10.50 --orig-dst 10.10.10.21 --dport 443
1 flow entries have been deleted.

Ce que cela signifie : Maintenant un nouveau SYN doit traverser vos règles actuelles. Si le blocage fonctionne seulement après cela, vos règles étaient correctes ; votre test ne l’était pas.

Décision : Ajustez votre méthode de validation et considérez si vous devez réinitialiser/abroger explicitement les flux établis lors d’incidents de sécurité.

Task 17: Verify policy routing / VRFs aren’t bypassing your expected interface

cr0x@server:~$ ip rule show
0:	from all lookup local
32766:	from all lookup main
32767:	from all lookup default

Ce que cela signifie : Si vous avez des règles additionnelles ici, le trafic peut emprunter un chemin de sortie différent de celui attendu, ce qui change les règles de pare‑feu pertinentes (surtout pour OUTPUT et FORWARD).

Décision : Si du routage de politique est présent, assurez‑vous que les règles du pare‑feu correspondent au chemin réel, pas au diagramme d’un slide.

Trois mini‑histoires du monde de l’entreprise (anonymisées, exactes, légèrement douloureuses)

Mini‑histoire 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne exploitait un cluster Proxmox supportant des outils internes : runners CI, stockage d’artefacts, et une poignée de VMs « temporaires » qui l’étaient depuis l’année fiscale précédente. Une revue de sécurité a signalé que plusieurs VMs étaient joignables sur des ports qu’elles ne devaient pas l’être. L’équipe infra a réagi rapidement : activer le pare‑feu Proxmox au niveau datacenter, appliquer un deny inbound par défaut sur le sous‑réseau VM, puis ouvrir des trous pour SSH depuis la jump box.

Ils ont testé en lançant iptables -S et ont vu les chaînes attendues. Super. Ils ont lancé un scan de ports et ont continué à voir des ports ouverts. Pas super. La conclusion, livrée avec une confiance totale, a été que le pare‑feu Proxmox « ne fonctionne pas de manière fiable » et la modification a été annulée.

La mauvaise hypothèse : ils lisaient iptables-legacy, alors que le filtrage réel vivait dans nftables. L’hôte avait été mis à jour sur place. Certains scripts anciens appelaient les outils legacy, et avec le temps le nœud était entré en split‑brain : les tables legacy contenaient les « bonnes » règles, nftables était essentiellement permissif, et le trafic en direct suivait les hooks nftables. Leur « vérification » ne vérifiait qu’un langage mort.

Une fois qu’ils ont standardisé les alternatives vers iptables-nft, désactivé les scripts legacy et forcé pve-firewall à réappliquer, le pare‑feu s’est comporté parfaitement — parce qu’il avait en fait toujours bien fonctionné. L’incident n’était pas « le pare‑feu Proxmox est instable ». L’incident était « nous regardions le mauvais plan de contrôle et nous nous sommes fait confiance ».

Le correctif durable était ennuyeux : une vérification de bootstrap des nœuds qui échoue si les alternatives iptables diffèrent à travers le cluster. Cette garde‑fou a empêché le même drame lors de la fenêtre de mise à jour suivante.

Mini‑histoire 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation faisait tourner des environnements multi‑tenant dev sur Proxmox. Ils voulaient un « apply plus rapide » du pare‑feu car les développeurs se plaignaient que le provisioning d’une VM prenait trop de temps. Quelqu’un a remarqué que pve-firewall réappliquait beaucoup de règles fréquemment, surtout avec un churn de config. L’« optimisation » : introduire une config de base nftables avec flush ruleset et une allowlist minimale, puis laisser Proxmox ajouter ses propres tables ensuite.

En lab, cela paraissait propre. En production, cela a créé une course : nftables.service rechargeait lors d’événements réseau et effaçait le ruleset. Proxmox finissait par réappliquer, mais « finalement » n’est pas un contrôle de sécurité. Entre la purge et la réapplication, des VMs étaient brièvement exposées. Pas pendant des heures, mais assez longtemps pour que les logs soient mauvais et que les auditeurs aient des opinions.

Le revers n’était pas seulement la purge. C’était l’existence de deux autorités concurrentes sur le même objet noyau. nftables.service croyait détenir la vérité. Proxmox croyait détenir la vérité. Le noyau exécutait la vérité qui avait été écrite en dernier.

L’équipe est revenue à un modèle à propriétaire unique : Proxmox génère l’état du pare‑feu ; nftables.service est désactivé ; toute configuration d’endurcissement de l’hôte est exprimée comme règles datacenter/node Proxmox. Le « apply rapide » a été atteint en réduisant le churn inutile de règles (moins de micro‑règles par VM, plus d’utilisation d’ensembles et de groupes) plutôt qu’en construisant un second plan de contrôle.

La leçon : si votre optimisation repose sur la purge d’un ruleset vivant, vous n’avez pas optimisé ; vous avez introduit du jeu avec des étapes supplémentaires.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une entreprise régulée exploitait trois clusters Proxmox avec des rôles identiques. Ils avaient une politique de changement : avant d’activer le pare‑feu globalement, ils mettent en scène en mode « log uniquement », valident les compteurs, puis appliquent. Les gens râlaient que c’était lent et bureaucratique. C’était aussi précisément pourquoi le déploiement ne s’est pas transformé en incident nocturne.

En staging, ils ont remarqué quelque chose de subtil : le trafic VM→VM sur le même bridge ne passait pas par le chemin de filtrage attendu sur un cluster. Les compteurs ne bougeaient pas. Les logs ne montraient pas de drops. Les règles étaient là — mais sans effet.

Parce qu’ils mesuraient avant d’appliquer, ils ont trouvé que les sysctls br_netfilter étaient désactivés sur ce cluster. Un profil de tuning noyau avait désactivé le filtrage bridge des années auparavant pour « réduire la charge ». La réduction de charge était réelle. Le contournement de sécurité l’était aussi.

Ils ont corrigé les sysctls, confirmé que les compteurs augmentaient pour le trafic de test, puis ont poursuivi avec l’application. Pas de surprises, pas de « pourquoi tout est indisponible », et pas d’exceptions d’urgence qui durent pour toujours. La pratique ennuyeuse — instrumenter d’abord, appliquer ensuite — les a empêchés d’expédier un pare‑feu placebo.

Erreurs courantes : symptôme → cause → correctif

• Symptôme : l’interface Proxmox montre le pare‑feu activé ; le trafic n’est pas bloqué.
  Cause : règles appliquées à nftables mais vous inspectez iptables‑legacy (ou l’inverse).
  Correctif : Standardisez les alternatives (iptables‑nft recommandé), puis redémarrez pve-firewall et validez avec nft list ruleset.
• Symptôme : les règles s’appliquent, puis disparaissent au bout de quelques minutes ou après un reload réseau.
  Cause : nftables.service charge /etc/nftables.conf avec flush ruleset, ou un autre gestionnaire réécrit les tables.
  Correctif : Désactivez le service concurrent ou supprimez le comportement flush/replace ; choisissez un seul propriétaire du ruleset.
• Symptôme : les règles VM n’affectent pas le trafic VM→VM sur le même bridge.
  Cause : sysctls bridge netfilter désactivés (net.bridge.bridge-nf-call-iptables=0).
  Correctif : Activez br_netfilter et les sysctls de façon persistante ; retestez avec compteurs/logs.
• Symptôme : « j’ai bloqué le port X, mais ma session est toujours ouverte. »
  Cause : conntrack permet les flux établis ; votre règle n’affecte que les nouvelles connexions.
  Correctif : Testez avec de nouvelles connexions, ou purgez des entrées conntrack spécifiques, ou ajustez l’ordre des règles si vous devez vraiment tuer les flux établis.
• Symptôme : un seul nœud du cluster applique les règles ; les autres non.
  Cause : dérive de nœud : alternatives différentes (legacy vs nft), sysctls différents, services activés différents.
  Correctif : Comparez les nœuds : alternatives, sysctls, modules chargés, services activés ; standardisez via gestion de configuration.
• Symptôme : NAT/forwardings se comportent différemment après activation du pare‑feu.
  Cause : tables NAT mixées iptables/nft ; docker ou autres composants insérant des règles NAT ; différences d’ordre.
  Correctif : Consolidez la propriété du NAT ; inspectez la table nat nft et assurez‑vous que les règles Proxmox ne sont pas en conflit avec les runtimes de containers.
• Symptôme : l’accès de gestion de l’hôte est bloqué de façon inattendue.
  Cause : application d’un « deny inbound » au niveau datacenter sans allow explicite pour SSH/GUI/cluster/storage, ou application à la mauvaise interface.
  Correctif : Toujours déployer en mode log‑only d’abord ; ajouter des allow explicites pour le plan de management ; valider les bindings d’interface.
• Symptôme : les logs du pare‑feu montrent des drops, mais le trafic passe encore.
  Cause : vous loggez un chemin (par ex. INPUT) alors que le trafic emprunte FORWARD/bridge, ou le chemin IPv6 est différent.
  Correctif : Identifiez le hook réel avec interface et direction ; vérifiez les règles de la famille inet ; incluez IPv6 si utilisé.

Listes de contrôle / plan pas à pas

Checklist A: Standardiser un nœud Proxmox sur un seul backend de pare‑feu

1. Choisissez votre backend : sur Proxmox/Debian moderne, optez pour iptables‑nft/nftables sauf exigence fournisseur pour legacy.
2. Vérifiez les alternatives pour iptables/ip6tables/ebtables/arptables.
3. Supprimez ou désactivez les scripts legacy qui appellent iptables-legacy.
4. Désactivez les gestionnaires de pare‑feu concurrents (ufw/firewalld) sauf intégration délibérée.
5. Redémarrez pve-firewall et vérifiez les règles actives via nft.

Checklist B: Valider que le trafic VM atteint bien netfilter

1. Confirmez le chemin bridge : le trafic utilise vmbrX et les dispositifs tap/veth attendus.
2. Assurez‑vous que le module br_netfilter est chargé.
3. Activez les sysctls bridge pour iptables/ip6tables si vous comptez sur le filtrage hôte pour le trafic ponté.
4. Utilisez des compteurs/règles de log pour prouver que les paquets correspondent.

Checklist C: Tester des changements de pare‑feu sans se tromper

1. Utilisez une nouvelle connexion TCP (nouveau port source) ou un client différent.
2. Vérifiez les compteurs pour la règle/chaîne spécifique.
3. Si nécessaire, supprimez des entrées conntrack spécifiques pour des retests propres.
4. Validez le comportement IPv4 et IPv6 ; « fonctionne en v4 » n’est pas « sécurisé ».

Plan de remédiation pas à pas (celui que j’exécuterais en production)

1. Geler les écrivains de règles : arrêter/désactiver temporairement les gestionnaires de pare‑feu non Proxmox (nftables.service, ufw, firewalld) pour éviter le churn pendant le diagnostic.
2. Confirmer le backend : vérifier update-alternatives --display iptables et s’accorder sur nft vs legacy sur tous les nœuds.
3. Inspecter le ruleset actif : utiliser nft list ruleset et s’assurer que les structures générées par Proxmox apparaissent et que les compteurs augmentent lors des tests.
4. Corriger la visibilité des bridges : s’assurer que br_netfilter + sysctls correspondent à votre modèle de filtrage.
5. Réactiver seulement ce dont vous avez besoin : laisser Proxmox posséder l’état du pare‑feu ; réintroduire d’autres outils uniquement s’ils sont strictement nécessaires et non‑chevauchants.
6. Verrouiller la cohérence : codifier les alternatives/sysctls/activation des services dans la gestion de configuration ; ajouter une vérification de dérive dans la validation santé des nœuds.

FAQ

1) Pourquoi les règles du pare‑feu Proxmox « ne s’appliquent pas » alors que l’interface dit activé ?

Parce que l’interface est une interface de configuration, pas le noyau. La cause la plus commune est un décalage de backend : les règles sont appliquées à nftables tandis que vous inspectez iptables legacy, ou un autre service purge/remplace les règles après l’application de Proxmox.

2) nftables est‑il meilleur qu’iptables pour Proxmox ?

En 2025 : oui, opérationnellement, car c’est le défaut moderne sur les systèmes Debian et cela évite la dérive des outils legacy. La mauvaise réponse est « les deux », sauf si vous aimez déboguer des piles de règles en split‑brain.

3) iptables et nftables peuvent‑ils fonctionner en même temps ?

Malheureusement oui. Vous pouvez avoir des règles iptables‑legacy et nftables simultanément. C’est ainsi que vous obtenez « je vois la règle mais elle ne fonctionne pas ». Choisissez un backend et standardisez.

4) Comment savoir si iptables utilise nftables en dessous ?

Utilisez update-alternatives --display iptables. Si cela pointe vers /usr/sbin/iptables-nft, vos commandes iptables programment des règles compatibles nftables.

5) Mon trafic VM→VM n’est pas filtré. Le pare‑feu Proxmox est‑il cassé ?

Habituellement non. Le trafic VM→VM sur le même bridge est du switching L2. Si les sysctls br_netfilter sont désactivés, netfilter ne verra pas ces paquets. Activez br_netfilter et les sysctls pertinents si votre modèle de sécurité dépend du filtrage sur l’hôte.

6) Pourquoi bloquer un port n’a‑t‑il pas déconnecté des sessions existantes ?

Conntrack. Beaucoup de règles acceptent established,related tôt pour la performance et la stabilité. Votre nouveau blocage affecte les nouvelles connexions. Testez avec une nouvelle connexion ou supprimez l’entrée conntrack spécifique si vous avez besoin d’une validation propre.

7) Dois‑je exécuter nftables.service sur un hôte Proxmox ?

Si Proxmox est votre gestionnaire autoritatif, typiquement non. Exécuter nftables.service avec une config qui purge ou remplace les règles entrera en conflit. Si vous devez l’exécuter, assurez‑vous qu’il n’efface pas ou n’écrase pas les tables gérées par Proxmox et que l’ordre de démarrage est déterministe.

8) Pourquoi ça fonctionne sur un nœud et pas sur un autre du même cluster ?

La config du cluster peut être identique alors que l’état local du nœud diffère : sélection d’alternatives, services activés, sysctls, modules noyau, ou agents tiers. Comparez les paramètres locaux des nœuds ; ne supposez pas que le cluster rend tout uniforme.

9) Dois‑je me soucier d’IPv6 si mon réseau est « only IPv4 » ?

Si IPv6 est activé sur des interfaces, des services peuvent se lier en IPv6 et devenir joignables. Gérez IPv6 explicitement (préférable) ou désactivez IPv6 de manière délibérée et cohérente. « Nous n’utilisons pas IPv6 » signifie souvent « nous ne monitorons pas IPv6 ».

Conclusion : prochaines étapes qui tiennent

Quand les règles du pare‑feu Proxmox ne s’appliquent pas, traitez cela comme tout autre problème de fiabilité en production : établissez le plan de contrôle réel, confirmez la propriété, et prouvez le chemin des paquets avec des compteurs — pas avec des impressions.

Étapes pratiques :

1. Décidez de votre backend de pare‑feu (nftables/iptables‑nft est le choix raisonnable) et standardisez update-alternatives sur tous les nœuds.
2. Faites de Proxmox la source unique de vérité pour le filtrage hôte/VM, sauf raison technique documentée pour séparer la propriété.
3. Auditez et supprimez le churn de règles : désactivez nftables.service/ufw/firewalld sur les hôtes PVE sauf si intégrés ; surveillez l’insertion de règles par docker/kube.
4. Validez le comportement des bridges avec les sysctls br_netfilter et des compteurs réels, surtout pour le trafic VM→VM.
5. Améliorez vos tests : nouvelles connexions, conscience de conntrack, et validation explicite IPv4/IPv6.

Faites‑le une fois, documentez‑le, et votre futur vous n’aura plus à « redécouvrir » la différence entre une règle qui existe et une règle qui est réellement appliquée.