Résoudre l’échec de pve-firewall.service sur Proxmox sans se verrouiller dehors

novembre 14, 2025 • février 3, 2026 • Lecture : 27 min • Views: 10

Cet article vous a aidé ?

Votre hôte Proxmox démarre, les VM sont actives, le cluster a l’air normal—puis l’interface web commence à répondre lentement, SSH devient « saccadé », et systemd lâche la petite bombe : pve-firewall.service failed. L’instinct est de le redémarrer jusqu’à ce qu’il se comporte. C’est justement comme ça qu’on finit par devoir se rendre au datacenter ou supplier quelqu’un qui a un accès physique à la console.

Voici la façon sûre : conservez une ligne de gestion, trouvez la règle/la configuration exacte qui a cassé, et remettez le firewall en route sans transformer votre nœud en un déni de service auto-infligé.

Ce que fait réellement pve-firewall (et pourquoi il échoue)

Le firewall de Proxmox VE (PVE) n’est pas « juste iptables ». C’est un générateur et un orchestrateur de règles qui lit la configuration depuis plusieurs emplacements (datacenter, nœud, VM), compile cela en jeux de règles, puis les installe sur l’hôte et éventuellement sur les bridges/tap des invités. Quand il fonctionne, c’est agréablement ennuyeux. Quand il échoue, vous avez deux types de problèmes :

Le service ne démarre pas : les règles ne sont jamais installées, ou des règles partielles restent selon l’endroit où le processus a planté.
Le service démarre mais votre accès meurt : les règles s’installent correctement — mais vos hypothèses sur les réseaux de gestion, les ports du cluster ou le filtrage des bridges étaient fausses.

systemd est catégorique : si les scripts d’aide retournent un code non nul, pve-firewall.service est marqué comme failed. Ce code non nul est souvent un problème de syntaxe (définition de règle invalide), une dépendance manquante (modules noyau / backends xtables), ou un conflit (votre propre gestionnaire nftables/iptables qui marche sur les règles de PVE).

Il y a une raison pour laquelle les opérateurs expérimentés deviennent un peu tendus autour des redémarrages du firewall : le firewall est l’un des rares composants qui peut casser votre unique méthode pour réparer le firewall. C’est un problème très caractéristique d’ingénierie.

Un principe de fiabilité à garder en tête — idée paraphrasée de Gene Kim (auteur DevOps) : « De petits changements sûrs valent mieux que des réparations héroïques sous pression. » C’est toute l’approche ici : isoler, valider, puis appliquer de façon à préserver l’accès.

Feuille de route de diagnostic rapide

Si vous êtes en pleine incident, ne commencez pas par « ajuster les règles ». Commencez par trouver ce qui est cassé et si vous avez encore une corde de sécurité.

Première étape : confirmer les chemins d’accès

Avez-vous un accès console hors bande (IPMI/iDRAC/iLO) ou un accès physique ?
Avez-vous une session SSH existante que vous pouvez garder ouverte ?
Pouvez-vous ouvrir une seconde session depuis un autre réseau (VPN, bastion) comme secours ?

Deuxième étape : lisez l’erreur, ne devinez pas

systemctl status pve-firewall pour la dernière ligne d’erreur.
journalctl -u pve-firewall -b pour le journal complet.
Vérifiez les configs dans /etc/pve/firewall/ pour des problèmes de syntaxe si les logs mentionnent un parsing.

Troisième étape : déterminez le backend et les conflits

iptables --version et update-alternatives --display iptables
Est-ce que nftables tourne ? Est-ce que ufw ou firewalld sont installés ?

Quatrième étape : isolez ce qui a changé

Mises à jour récentes ? Noyau ? Version PVE ?
Éditions récentes dans les onglets Firewall Datacenter/Nœud/VM ?
Automatisation touchant /etc/network/interfaces ou /etc/pve ?

Si vous ne faites qu’une chose de cette feuille de route : récupérez les logs et validez les configs avant de redémarrer quoi que ce soit en boucle. Les redémarrages répétés transforment un bug déterministe en une panne dépendante du temps.

Sécurité d’abord : ne vous verrouillez pas hors du système

Quand le firewall est cassé, votre objectif n’est pas la « sécurité maximale ». Votre objectif est de « restaurer une connectivité contrôlée » afin de finir la réparation. Cela signifie :

Gardez au moins une session root ouverte (SSH ou console) pendant que vous testez les changements.
Préférez l’accès console si disponible. Il est immunisé contre vos propres règles de firewall.
Échelonnez les changements et utilisez un rollback programmé quand c’est possible.
Ne rechargerez pas les bridges réseau à la légère sauf si vous comprenez comment votre nœud transporte le trafic de gestion.

Petite blague #1 : Un redémarrage de firewall, c’est comme changer un pneu sur l’autoroute — faites-le, mais ne soyez pas étonné que ce soit excitant.

Deux schémas de sécurité pragmatiques :

Schéma A : « Deux sessions et un minuteur »

Ouvrez deux sessions root. Dans la session n°2, planifiez un rollback (désactiver le firewall ou restaurer une config connue) dans 2–5 minutes. Dans la session n°1, tentez la correction. Si vous perdez l’accès, attendez que le rollback vous sauve.

Schéma B : « Console d’abord pour les étapes risquées »

Si vous avez IPMI/iLO/etc., effectuez les opérations risquées (redémarrage du service, application de nouvelles règles, modification du filtrage de bridge) depuis la console. Ainsi votre transport ne dépend pas de la chose que vous modifiez.

Tâches pratiques (commandes, sorties, décisions)

Ci-dessous des tâches pratiques que vous pouvez exécuter sur un nœud Proxmox. Chacune indique ce que la sortie signifie généralement et la décision à prendre ensuite. Les commandes sont volontairement conservatrices : collecter des faits, valider la config, puis appliquer des changements avec contrôle.

Task 1: Confirm the service state and last error line

cr0x@server:~$ systemctl status pve-firewall --no-pager
● pve-firewall.service - Proxmox VE firewall
     Loaded: loaded (/lib/systemd/system/pve-firewall.service; enabled)
     Active: failed (Result: exit-code) since Fri 2025-12-26 10:13:02 UTC; 3min ago
    Process: 1462 ExecStart=/usr/sbin/pve-firewall start (code=exited, status=255/EXCEPTION)
   Main PID: 1462 (code=exited, status=255/EXCEPTION)

Dec 26 10:13:02 server pve-firewall[1462]: error parsing cluster firewall configuration: /etc/pve/firewall/cluster.fw line 42
Dec 26 10:13:02 server systemd[1]: pve-firewall.service: Main process exited, code=exited, status=255/EXCEPTION
Dec 26 10:13:02 server systemd[1]: pve-firewall.service: Failed with result 'exit-code'.
Dec 26 10:13:02 server systemd[1]: Failed to start Proxmox VE firewall.

Ce que cela signifie : Vous avez une erreur de parsing ; c’est généralement une faute de frappe ou une ligne de règle invalide dans un fichier .fw.

Décision : Ne redémarrez pas encore. Inspectez le fichier et le numéro de ligne indiqué.

Task 2: Pull the full log for the current boot

cr0x@server:~$ journalctl -u pve-firewall -b --no-pager -n 200
Dec 26 10:13:02 server pve-firewall[1462]: starting firewall
Dec 26 10:13:02 server pve-firewall[1462]: reading configs...
Dec 26 10:13:02 server pve-firewall[1462]: error parsing cluster firewall configuration: /etc/pve/firewall/cluster.fw line 42
Dec 26 10:13:02 server pve-firewall[1462]: stopping firewall (cleanup)
Dec 26 10:13:02 server pve-firewall[1462]: cleanup done
Dec 26 10:13:02 server systemd[1]: pve-firewall.service: Main process exited, code=exited, status=255/EXCEPTION

Ce que cela signifie : Le service a bien démarré le processus, a lu la config, puis a abandonné proprement après l’erreur. Le cleanup suggère qu’il a tenté de supprimer des règles partielles.

Décision : Corrigez la configuration. Si le cleanup n’a pas eu lieu, vous devrez peut-être purger des règles cassées plus tard.

Task 3: Verify whether firewall is enabled at all levels

cr0x@server:~$ pve-firewall status
Status: stopped
Enabled: 1
Nodes:
  server: enabled=1
VMs:
  101: enabled=0
  102: enabled=1

Ce que cela signifie : Le firewall est activé globalement et sur le nœud ; il est actuellement arrêté en raison de l’échec.

Décision : Si vous avez besoin d’un mouvement temporaire « ramenez-moi », désactivez au niveau datacenter/nœud (avec la console prête). Sinon, poursuivez la correction et le redémarrage.

Task 4: Check cluster filesystem health (because configs live there)

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod
Config Version:   42
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Fri Dec 26 10:16:40 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2a
Quorate:          Yes

Ce que cela signifie : Le cluster a le quorum ; /etc/pve devrait être inscriptible et cohérent.

Décision : Si le cluster n’est pas quorate, vous pouvez rencontrer des configs obsolètes/partielles et les modifications peuvent ne pas s’appliquer. Réparez d’abord le quorum/stockage.

Task 5: Find the bad line fast

cr0x@server:~$ nl -ba /etc/pve/firewall/cluster.fw | sed -n '35,55p'
    35  [OPTIONS]
    36  enable: 1
    37
    38  [RULES]
    39  IN ACCEPT -p tcp --dport 8006 -source +mgmt
    40  IN ACCEPT -p tcp --dport 22 -source +mgmt
    41  IN DROP -p tcp --dport 3306 -source 0.0.0.0/0
    42  IN ACCEPT -p tcp --dport abc -source +mgmt

Ce que cela signifie : --dport abc est invalide. Le parser du firewall PVE le rejette.

Décision : Remplacez par un port numérique ou un service/alias valide si supporté par votre style de règle. Puis retestez.

Task 6: Validate you didn’t break an alias/group reference

cr0x@server:~$ grep -R --line-number -E '^\s*(group|alias):' /etc/pve/firewall
/etc/pve/firewall/cluster.fw:12:group: mgmt 10.10.0.0/24
/etc/pve/firewall/cluster.fw:13:alias: dns1 10.10.0.53

Ce que cela signifie : Votre group/alias existe. Si votre règle référence +mgmt, elle devrait se résoudre.

Décision : Si le group/alias est manquant ou mal orthographié, corrigez cela plutôt que la règle elle-même.

Task 7: Dry-run thinking: check current ports you must not break

cr0x@server:~$ ss -lntp | egrep '(:22|:8006|:5900|:3128|:5405|:5404|:60000)'
LISTEN 0      128          0.0.0.0:22        0.0.0.0:*    users:(("sshd",pid=1120,fd=3))
LISTEN 0      4096         0.0.0.0:8006      0.0.0.0:*    users:(("pveproxy",pid=1408,fd=6))
LISTEN 0      128        127.0.0.1:3128      0.0.0.0:*    users:(("pveproxy",pid=1408,fd=9))
LISTEN 0      4096         0.0.0.0:5900      0.0.0.0:*    users:(("vncshell",pid=1550,fd=5))

Ce que cela signifie : Les services de gestion écoutent. Le firewall doit autoriser vos réseaux de gestion à atteindre 22/8006 au minimum.

Décision : Si vous n’autorisez pas explicitement vos sous-réseaux source, ne redémarrez pas le firewall encore. Ajoutez d’abord une règle allow.

Task 8: Check whether you’re on nftables or legacy iptables backend

cr0x@server:~$ iptables --version
iptables v1.8.9 (nf_tables)

Ce que cela signifie : iptables utilise le backend nf_tables. C’est acceptable, mais cela modifie le comportement des conflits et l’apparence des règles.

Décision : Si vous avez des scripts qui attendent une sortie legacy, ils peuvent mal détecter les règles et « corriger » les choses incorrectement. Auditez l’automatisation.

Task 9: Look for conflicting firewall managers

cr0x@server:~$ systemctl is-active nftables ufw firewalld 2>/dev/null
inactive
inactive
inactive

Ce que cela signifie : Aucun service concurrent ne gère activement les règles.

Décision : Si l’un est actif, désactivez-le ou décidez explicitement qui gère les règles. Deux chefs dans une même soupe, même fin.

Task 10: Confirm bridge firewalling settings (common lockout lever)

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 : Le trafic ponté passe par les règles iptables/nft. Avec le firewall PVE activé, c’est attendu pour le filtrage des VM.

Décision : Si vous ne vouliez pas filtrer le trafic de bridge, vous pourriez en filtrer votre propre chemin de gestion (selon la topologie). Validez comment la gestion atteint l’hôte (NIC direct vs bridge).

Task 11: See if a kernel module dependency is missing

cr0x@server:~$ lsmod | egrep 'br_netfilter|nf_tables|ip_tables|x_tables'
br_netfilter           32768  0
nf_tables             286720  1429 nft_chain_nat,nft_counter,nft_ct,nft_compat
x_tables               53248  9 xt_conntrack,iptable_filter,iptable_nat,xt_MASQUERADE,nft_compat,xt_tcpudp,xt_addrtype,xt_nat,xt_comment
ip_tables              32768  2 iptable_filter,iptable_nat

Ce que cela signifie : Les éléments communs sont présents. Si vous ne voyez rien de pertinent, un problème minimal de noyau/modules peut exister.

Décision : Si des modules manquent après une mise à jour du noyau, redémarrez sur le noyau correct ou réinstallez les paquets correspondants.

Task 12: Safely schedule a rollback before attempting restart

cr0x@server:~$ at now + 3 minutes <<'EOF'
systemctl stop pve-firewall
echo "Rollback executed: stopped pve-firewall at $(date)" >> /root/pve-firewall-rollback.log
EOF
warning: commands will be executed using /bin/sh
job 7 at Fri Dec 26 10:23:00 2025

Ce que cela signifie : Vous avez planifié un « interrupteur de l’homme mort ». Si vous vous verrouillez dehors, l’hôte arrêtera le service pve-firewall peu après.

Décision : Procédez au redémarrage/test. Si tout va bien, supprimez le job : atrm 7.

Task 13: Restart the firewall and confirm it stays active

cr0x@server:~$ systemctl restart pve-firewall
cr0x@server:~$ systemctl is-active pve-firewall
active

Ce que cela signifie : Le service a démarré avec succès.

Décision : Validez immédiatement que vous pouvez toujours atteindre SSH et l’interface web depuis votre réseau de gestion. Puis annulez le job de rollback.

Task 14: Verify rules exist and default policy isn’t silently hostile

cr0x@server:~$ iptables -S | sed -n '1,60p'
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-N PVEFW-INPUT
-A INPUT -j PVEFW-INPUT
-A PVEFW-INPUT -p tcp -m tcp --dport 22 -s 10.10.0.0/24 -j ACCEPT
-A PVEFW-INPUT -p tcp -m tcp --dport 8006 -s 10.10.0.0/24 -j ACCEPT
-A PVEFW-INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A PVEFW-INPUT -i lo -j ACCEPT

Ce que cela signifie : La politique INPUT par défaut est DROP (normal pour le firewall PVE). Vos allow explicites pour les ports de gestion existent.

Décision : Si la politique est DROP mais que vous ne voyez pas de règles allow pour votre réseau source, arrêtez et corrigez les règles avant de fermer votre session de travail.

Task 15: Confirm the GUI proxy is reachable from your client network

cr0x@server:~$ curl -k -m 2 -I https://127.0.0.1:8006/ | head
HTTP/1.1 200 OK
server: pve-api-daemon
content-type: text/html; charset=utf-8

Ce que cela signifie : Le service est joignable en local. Si les clients distants ne peuvent toujours pas y accéder, c’est un problème de firewall ou de routage.

Décision : Testez depuis un poste de gestion sur le même sous-réseau ; si c’est bloqué à distance, inspectez le matching de l’adresse source et les chemins bridge/NIC.

Task 16: If you must temporarily disable PVE firewall, do it cleanly

cr0x@server:~$ pve-firewall stop
stopping firewall...
firewall stopped

Ce que cela signifie : Les règles PVE sont supprimées et le service est arrêté (selon votre environnement, des politiques de base peuvent rester).

Décision : N’utilisez ceci que pendant une courte fenêtre de maintenance pour restaurer la bonne config. Puis réactivez. « Temporaire » a tendance à devenir un mode de vie.

Causes racines qui font échouer pve-firewall.service

La plupart des échecs retombent dans quelques catégories. Connaître la catégorie vous évite de batailler dans le vide.

1) Erreurs de syntaxe dans les fichiers de configuration du firewall PVE

Ce sont les plus courantes et les plus réparables. Le message d’erreur pointe souvent directement un fichier et une ligne. Causes typiques :

Port non numérique dans --dport ou --sport
Mauvaise notation CIDR
Macro ou option non reconnue
Copier/coller de règles iptables que le parser PVE n’accepte pas littéralement
Caractères invisibles provenant de « guillemets intelligents » collés depuis un ticket

Le signe révélateur : les logs disent « error parsing … line N ». Corrigez la ligne, redémarrez, terminé.

2) Conflits avec la gestion nftables/iptables

Le firewall PVE s’attend à posséder des chaînes spécifiques et à insérer des hooks d’une certaine façon. Si un autre service vide les tables, change les politiques par défaut, ou utilise des noms de chaînes conflictuels, vous pouvez obtenir une installation partielle ou un filtrage inattendu.

Parfois rien ne « plante » au niveau systemd ; vous perdez simplement du trafic. Pire. Le service est « active », et la panne devient une faute subtile de votre côté.

3) Incompatibilité noyau/module après des mises à jour

Moins fréquent sur des nœuds PVE stables, mais ça arrive quand :

Vous avez mis à jour les paquets du noyau sans redémarrer (et vous avez changé les backends/compat layers du firewall).
Vous avez démarré sur un noyau ancien manquant des éléments netfilter attendus par l’espace utilisateur actuel.
Vous utilisez un noyau personnalisé ou des modules minimaux, et les outils Proxmox supposent des valeurs par défaut.

4) Filtrage de bridge et confusion sur le chemin du trafic de gestion

Beaucoup d’hôtes Proxmox placent l’IP de gestion sur un bridge Linux (vmbr0) pour que l’hôte et les VM partagent l’uplink. Avec bridge netfilter activé, votre trafic de gestion hôte peut être soumis au même filtrage que le trafic VM. Cela peut aller — si vous l’avez conçu. Sinon, c’est un moyen facile de vous verrouiller dehors.

Petite blague #2 : Si votre IP de gestion vit sur un bridge, vous avez essentiellement mis votre propre SSH dans des montagnes russes et appelé ça « conception réseau ».

5) Bizarreries de propagation de config du cluster

La configuration du firewall PVE est stockée sous /etc/pve, qui repose sur le filesystem de cluster (pmxcfs). Si pmxcfs est malheureux (disque plein, problèmes FUSE, sauts de temps, perte de quorum), vous pouvez éditer des configs qui ne s’appliquent pas correctement ou de façon incohérente entre nœuds.

6) Surprises IPv6

Même si vous n’« utilisez » pas IPv6, votre système peut l’utiliser. L’interface web peut écouter sur IPv6, ou les clients peuvent préférer les enregistrements AAAA. Si vous n’autorisez que l’IPv4 et que vos clients arrivent via IPv6, ça ressemble à une panne aléatoire. Ce n’est pas aléatoire. C’est une confusion déterministe.

Erreurs courantes : symptôme → cause → correction

1) Symptom: `pve-firewall.service` fails immediately with a line number

Cause racine : Erreur de syntaxe dans /etc/pve/firewall/*.fw (cluster, nœud ou VM).

Correction : Utilisez journalctl -u pve-firewall -b et nl -ba pour localiser la ligne. Supprimez/réparez le token invalide (ports, CIDR, options). Redémarrez et confirmez que c’est actif.

2) Symptom: Service is active, but GUI/SSH is unreachable from a subset of networks

Cause racine : Vous avez autorisé le mauvais sous-réseau source (souvent un bastion NATé, un pool VPN ou une nouvelle plage WAN). Ou vous n’avez autorisé que l’IPv4 alors que les clients arrivent en IPv6.

Correction : Confirmez les IP sources côté client et dans les logs. Étendez la règle allow vers le bon groupe mgmt. Ajoutez des règles IPv6 équivalentes si nécessaire. Vérifiez avec iptables -S/ip6tables -S et un test client.

3) Symptom: Restarting firewall intermittently drops cluster communications

Cause racine : Les ports corosync ne sont pas permis (ou vous filtrez sur la mauvaise interface). Le clustering Proxmox est bavard et sensible à la perte de paquets.

Correction : Assurez-vous que le réseau de cluster et le trafic nœud-à-nœud sont autorisés sur les interfaces appropriées. Si vous séparez cluster et gestion, gardez les règles séparées et explicites. Validez avec pvecm status et une capture si besoin.

4) Symptom: VM traffic dies when you enable host firewall

Cause racine : Bridge netfilter plus politique FORWARD DROP sans règles correctes par bridge/VM. Ou vous avez activé le firewall sur les VM sans autoriser leur egress/ingress nécessaire.

Correction : Décidez si vous voulez le filtrage au niveau VM. Si oui, rédigez des règles pour le forwarding et les interfaces tap des VM ; testez une VM d’abord. Si non, désactivez le filtrage de bridge ou le firewall VM et concentrez les règles INPUT sur les services hôte.

5) Symptom: Firewall start fails after an upgrade; errors mention xtables/nft compatibility

Cause racine : Mismatch de backend (legacy vs nf_tables) ou sélection alternative conflictuelle.

Correction : Vérifiez iptables --version et l’état de update-alternatives. Choisissez un backend délibérément, puis assurez-vous que vos outils et attentes correspondent. Redémarrez si noyau/espace utilisateur sont désynchronisés.

6) Symptom: Changes in GUI don’t “stick,” or different nodes show different firewall behavior

Cause racine : Problèmes pmxcfs / quorum, ou édition du mauvais scope (datacenter vs nœud vs VM).

Correction : Confirmez le quorum, vérifiez pvecm status. Assurez-vous d’éditer la portée voulue. Si le quorum est instable, évitez de faire des changements de firewall en plein syndrome de cluster.

7) Symptom: You can reach GUI locally but not remotely, even though INPUT allows look correct

Cause racine : Changement de routage/VRF, reverse path filtering, ou trafic de gestion arrivant sur une interface différente de celle attendue (bond, VLAN sub-interface, port de bridge).

Correction : Inspectez les routes et les adresses d’interface, puis vérifiez le match par interface des règles. Utilisez ip route, ip -br a, et confirmez avec une capture (tcpdump) sur l’interface supposée utilisée.

Trois mini-récits tirés de la vie en entreprise

Mini-récit 1 : La panne causée par une mauvaise hypothèse

Dans une entreprise de taille moyenne, une équipe de virtualisation a « serré » les règles du firewall Proxmox pour n’autoriser que l’interface web (8006) et SSH (22) depuis le VLAN de gestion. Raisonnable, et cela aurait été correct si le VLAN de gestion était bien là où les administrateurs se connectaient réellement.

L’hypothèse erronée était subtile : la plupart des administrateurs se connectaient via un VPN, et le pool VPN ne faisait pas partie du VLAN de gestion. Le bastion qu’ils utilisaient était bien sur mgmt, mais la nouvelle politique bloquait aussi certaines connexions sortantes depuis ce bastion vers des outils internes, si bien que des personnes ont commencé à se connecter directement depuis leurs ordinateurs portables via le VPN. Ces connexions étaient maintenant mortes.

Le comportement avait une particularité : les sessions SSH existantes restaient actives (ESTABLISHED), donc on voyait « certaines personnes peuvent se connecter et d’autres non ». Cela a alimenté des débats sur DNS, caches de navigateur, et si le load balancer faisait des siennes. Ce n’était pas ça. Le firewall faisait exactement ce qu’on lui avait dit.

La correction n’a pas été d’« ouvrir tout ». Ils ont traité le pool VPN comme une source de gestion à part entière, l’ont ajoutée explicitement au groupe mgmt, puis ont validé depuis un chemin client réel. Ils ont aussi ajouté un élément à la checklist pré-changement : « Confirmer la plage d’IP source des humains. » Ennuyeux. Efficace.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation a jugé que les redémarrages de firewall PVE prenaient « trop de temps » pendant les maintenances. Quelqu’un a optimisé en ajoutant de l’automatisation qui vidait et rechargeait les règles directement avec des commandes nft au lieu d’utiliser pve-firewall. Le temps de reload a diminué. Le plan de contrôle s’est dégradé.

Pendant un temps, cela semblait réussi. Puis une mise à jour a changé la façon dont Proxmox générait les noms de chaînes et les hypothèses du script ont rompu. Le script a vaillamment vidé les tables, rechargé un sous-ensemble incomplet, et laissé des politiques par défaut dans un état qui blackholed le trafic de façon intermittente selon l’état du conntrack.

Le retour de bâton a été organisationnel autant que technique : personne ne « possédait » le comportement résultant. L’équipe Proxmox disait « nous n’avons pas changé la config », l’équipe réseau disait « le firewall est host-local », et l’équipe d’automatisation disait « le pipeline est vert ». Pendant ce temps, le cluster avait des événements de fencing périodiques parce que les paquets corosync tombaient pendant les fenêtres de reload.

Ils ont récupéré en supprimant la sur-ingéniosité. Ils ont laissé Proxmox posséder ses chaînes, et l’automatisation est passée à valider les configs PVE et appeler pve-firewall restart dans des fenêtres contrôlées, nœud par nœud. Le reload était plus lent, mais la plateforme a cessé de surprendre les gens. En production, la surprise est la fonctionnalité la plus coûteuse.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une grande entreprise exploitant Proxmox en edge avait pour pratique standard : tout changement de firewall doit inclure un job de rollback programmé sur le nœud lui-même, plus la vérification de l’accès console avant le changement. Les ingénieurs râlaient car ça ressemblait à de la cérémonie.

Un jour, un ingénieur a ajouté une règle datacenter pour dropper le trafic entrant vers une plage de ports utilisée par une appli legacy — bonne intention, tests insuffisants. La règle a accidentellement matché une plage plus large que prévu. Résultat : SSH bloqué depuis le réseau de l’ingénieur, et l’interface web arrêtée.

L’ingénieur n’a pas paniqué. Il a attendu. Trois minutes plus tard, le rollback a stoppé le service firewall, restaurant l’accès. Puis il s’est reconnecté, a corrigé la règle, validé avec une capture, et a réappliqué avec la même garde de sécurité. Pas de voyage au datacenter, pas d’opéra Slack à 2 h du matin.

C’est tout l’intérêt du processus ennuyeux : il n’empêche pas les erreurs. Il rend les erreurs survivables.

Listes de vérification / plan étape par étape

Voici la séquence que j’exécuterais sur un nœud réel quand pve-firewall.service échoue ou quand un redémarrage pourrait couper mon propre accès. C’est volontairement opiné, car l’ambiguïté est la manière dont naissent les pannes.

Plan étape par étape : réparer sans se verrouiller

Obtenir l’accès console si possible (IPMI/iLO ou physique). Si vous ne pouvez pas, ouvrez deux sessions SSH et ne les fermez pas.
Capturer l’état actuel : sauvegarder systemctl status, journalctl, et la sortie de iptables -S/nft list ruleset dans un fichier root pour comparaison ultérieure.
Vérifier si le service échoue à démarrer vs « démarre mais vous bloque ». Le chemin de correction diffère.
Lire l’erreur exacte depuis journalctl -u pve-firewall -b. Si elle nomme un fichier+ligne, allez corriger cela d’abord. Ne faites pas d’improvisation.
Valider les exigences de reachabilité de gestion : identifiez vos vraies plages IP sources (pools VPN, bastions, sous-réseaux admin). Mettez à jour les groups/aliases de firewall en conséquence.
Planifier un rollback avec at (ou garder la console prête). Toujours. C’est votre parachute.
Redémarrer pve-firewall une seule fois. S’il échoue encore, retournez aux logs ; ne spammez pas les redémarrages.
Confirmer les ports critiques (22/8006) atteignables depuis au moins un réseau admin. Testez depuis un hôte client, pas seulement en local.
Confirmer la santé du cluster après application : pvecm status et vérifiez l’absence d’instabilité corosync.
Annuler le rollback uniquement après confirmation : atrm le job, documentez le changement, et prévoyez de nettoyer les allowances temporaires.

Checklist : éléments de sécurité avant un changement de firewall

Accès console vérifié (ou deux sessions SSH ouvertes).
Rollback planifié (at now + 3 minutes).
Snapshot de configuration connu-good existant (copie de /etc/pve/firewall et sortie des règles).
Réseaux de gestion et pools VPN identifiés et présents en tant qu’aliases/groups.
Ports du cluster et besoins réseau de stockage compris (surtout en designs multi-NIC).
Changer appliqué sur un nœud d’abord dans un cluster.

Checklist : validation après changement

systemctl is-active pve-firewall affiche active.
SSH distant et interface web testés depuis de vrais réseaux admin.
Connectivité des VM validée si bridge/firewall VM activé.
Pas de nouvelles erreurs corosync ; le cluster reste quorate.
Job de rollback annulé.

Faits intéressants et contexte

Ce ne sont pas des trivia pour le plaisir. Ils expliquent pourquoi le firewall Proxmox se comporte ainsi, et pourquoi les corrections semblent parfois contre-intuitives.

Proxmox stocke la config du firewall dans le filesystem de cluster (/etc/pve via pmxcfs). C’est pratique — et cela signifie que « problèmes de config » peuvent aussi être « problèmes de santé du cluster ».
Linux est passé d’iptables à nftables au fil du temps, mais beaucoup d’outils parlent encore « iptables ». La couche de compatibilité peut être parfaitement fonctionnelle jusqu’à ce que quelqu’un suppose la stabilité du format de sortie.
Les politiques DROP par défaut sont normales dans le firewall Proxmox. L’attente est des allows explicites pour la gestion, le cluster et les services. Si vous êtes habitué à « ACCEPT par défaut », cela paraît agressif.
Le bridge netfilter existe parce que des gens voulaient filtrer le trafic ponté (VM sur des bridges Linux). Cela signifie aussi que vous pouvez accidentellement filtrer votre propre trafic hôte quand l’hôte vit sur ce bridge.
L’état conntrack rend les pannes incohérentes. Les sessions établies continuent de fonctionner tandis que les nouvelles échouent, ce qui fait chasser les équipes après des fantômes.
Le clustering Corosync est sensible à la perte de paquets et aux pics de latence. Un reload de firewall qui bloque brièvement le multicast/unicast peut ressembler à une instabilité de nœud.
La « possession » du firewall a un impact opérationnel. Si PVE possède les chaînes, laissez-le les gérer. Mélanger orchestrateurs (PVE + ufw + scripts ad hoc) engendre des Heisenbugs.
L’IPv6 fonctionne souvent « par accident » jusqu’à ce que ça casse. Les clients modernes peuvent le préférer, et les services Proxmox peuvent se binder dessus. Si vous n’en tenez pas compte explicitement, vous obtiendrez des rapports d’accès étranges.

FAQ

1) Pourquoi `pve-firewall.service` a-t-il échoué juste après que j’ai édité une règle dans la GUI ?

Parce que la GUI écrit dans un fichier .fw sous /etc/pve/firewall, et le service parse ce fichier. Un seul token invalide peut empêcher la compilation des règles et le service termine avec un code non nul. Consultez journalctl -u pve-firewall -b pour fichier+ligne.

2) Puis-je simplement désactiver le firewall et passer à autre chose ?

Vous pouvez, mais traitez cela comme une mesure d’urgence. Désactivez pour retrouver l’accès, corrigez la config, puis réactivez. Si la désactivation devient permanente, vous avez remplacé une politique contrôlée par de la pensée magique.

3) J’ai redémarré le firewall et maintenant SSH est mort. Quelle est la récupération la plus rapide ?

Utilisez la console hors bande et stoppez le service : systemctl stop pve-firewall ou pve-firewall stop. Puis corrigez les règles allow pour vos réseaux admin avant de le redémarrer. Si vous aviez un job de rollback planifié, attendez qu’il se déclenche.

4) Est-ce que le firewall Proxmox utilise nftables ou iptables ?

Il utilise la pile netfilter et les outils du système. Sur les systèmes Debian modernes vous verrez souvent iptables (nf_tables). Le point pratique : ne supposez pas le comportement legacy d’iptables ou le format de sortie dans les scripts.

5) Pourquoi les sessions SSH existantes survivent-elles alors que les nouvelles échouent ?

Conntrack. Beaucoup de politiques firewall autorisent ESTABLISHED,RELATED. Votre session déjà ouverte correspond à cela, tandis que de nouvelles connexions ne correspondent pas. C’est pourquoi « ça marche pour moi » n’est pas une preuve.

6) Comment savoir quel scope de firewall me bloque (Datacenter vs Nœud vs VM) ?

Commencez par les logs pour les erreurs de parsing (ils nomment le fichier). Pour des problèmes comportementaux, désactivez temporairement un scope à la fois (de préférence via console) et observez. Les règles datacenter sont les plus larges ; les règles nœud s’appliquent à l’hôte ; les règles VM affectent le trafic invité (et parfois le forwarding selon la configuration).

7) Dois-je autoriser les ports corosync dans le firewall ?

Si vous avez PVE firewall qui applique INPUT/FORWARD, oui — au moins sur les interfaces utilisées pour la communication du cluster. Si vous isolez le trafic de cluster sur un réseau dédié, restreignez les allow à ce réseau, pas au monde entier.

8) Et si je suspecte que pmxcfs/quorum cause des bizarreries de configuration firewall ?

Vérifiez pvecm status pour le quorum et confirmez que vous pouvez lire/écrire sous /etc/pve. Si le quorum est perdu, priorisez la restauration de la santé du cluster. Éditer la config firewall dans un cluster dégradé est une manière sûre de produire des incohérences.

9) Est-il sûr de purger manuellement les règles iptables/nft ?

Ça peut l’être, mais c’est un outil tranchant. Si vous purgeez des tables sans comprendre ce qui en dépend (NAT pour VM, restrictions trafic stockage, règles de cluster), vous pouvez créer de nouvelles pannes. Préférez corriger la config PVE et laisser PVE ré-appliquer proprement.

10) Dois-je mettre l’IP de gestion de Proxmox sur un bridge ?

C’est courant et cela peut aller. Mais une fois que la gestion vit sur un bridge, bridge netfilter et les politiques de forwarding font partie de votre histoire d’accès hôte. Si vous voulez des modes de panne plus simples, une NIC/VLAN de gestion dédiée non liée au forwarding VM est plus calme.

Conclusion : prochaines étapes sans risque

La correction sûre pour pve-firewall.service failed est rarement « réessayer ». C’est : lire le log, corriger l’erreur de configuration exacte, et redémarrer une fois — sous une garde de rollback — en confirmant que vous autorisez les réseaux réellement utilisés par les humains.

Prochaines étapes pratiques :

Récupérez journalctl -u pve-firewall -b et résolvez toute erreur de parsing fichier/ligne.
Définissez un groupe de gestion approprié (incluant pools VPN et bastions) et autorisez explicitement 22/8006 depuis celui-ci.
Adoptez l’habitude du « rollback temporisé » pour les changements firewall. Ça paraît paranoïaque jusqu’à ce que ça vous fasse gagner une heure.
Si vous avez des clusters, testez les changements de firewall sur un nœud d’abord et vérifiez le quorum après application.