Le pare-feu Proxmox vous a verrouillé : restaurer SSH/UI Web depuis la console sans panique

novembre 4, 2025 • février 3, 2026 • Lecture : 30 min • Views: 8

Cet article vous a aidé ?

Vous avez modifié une règle de pare‑feu dans Proxmox. Maintenant l’interface Web se met en timeout, SSH est hors service, et votre estomac envisage une sortie par la gorge. Vous n’êtes pas « down ». Vous êtes juste localement inaccessible — comme une pièce de musée.

Ceci est un guide de récupération orienté console pour quand la politique de pare‑feu de Proxmox bloque votre propre accès de gestion. Il est rédigé pour les personnes qui gèrent des systèmes en production : vous voulez le chemin le plus rapide et sûr pour retrouver SSH et le port 8006, et comprendre ce qui a échoué pour que cela ne se reproduise pas.

Playbook de diagnostic rapide

Si vous êtes verrouillé, votre travail n’est pas de « déboguer tout ». Votre travail est de restaurer un chemin de gestion fonctionnel, puis d’améliorer en toute sécurité. Voici la route la plus rapide qui évite d’empirer la situation.

Première étape : déterminer s’il s’agit du pare‑feu, d’un service ou du réseau

Pouvez‑vous atteindre la machine via la console ? Si oui, poursuivez. Sinon, votre problème est en amont (console hyperviseur, IPMI/iLO/DRAC, accès physique).
Le réseau de l’hôte est‑il opérationnel ? Vérifiez l’état du lien, l’adresse IP, la route par défaut. Si le réseau est cassé, le pare‑feu n’est pas le problème principal.
La pile de gestion Proxmox tourne‑t‑elle ? Vérifiez pveproxy (interface Web) et sshd (SSH). Si les services sont arrêtés, réparez d’abord les services.

Deuxième étape : confirmer que le pare‑feu est réellement actif

Vérifiez si le pare‑feu Proxmox est activé au niveau datacenter/nœud.
Vérifiez si pve-firewall tourne et s’il a installé des règles dans nftables/iptables.

Troisième étape : appliquer la récupération à moindre risque

Désactivez temporairement le service de pare‑feu Proxmox (systemctl stop pve-firewall) pour restaurer l’accès, ou
Injectez une règle d’autorisation étroite pour SSH et 8006 depuis votre(s) IP d’administration, puis rechargez le pare‑feu.

Quatrième étape : vérifiez depuis l’extérieur, puis corrigez la politique correctement

Vérifiez SSH et l’interface Web depuis une machine d’administration connue.
Examinez l’ensemble de règles qui a causé le verrouillage (datacenter vs nœud vs VM, input vs output, portée par interface).
Mettez en place une stratégie permanente d’« allowlist » pour la gestion, pas un empilement d’exceptions.

Fait brut : si vous n’êtes pas sûr de la règle fautive, arrêtez de deviner. Désactivez le pare‑feu, restaurez l’accès, puis corrigez les règles à la lumière du jour.

Comment fonctionne réellement le pare‑feu Proxmox (les éléments importants en cas de panne)

Proxmox VE dispose d’une fonctionnalité de pare‑feu intégrée à l’interface, organisée en couches :

Datacenter : règles globales sur les nœuds (intention au niveau cluster).
Nœud : règles spécifiques à l’hôte, souvent pour l’accès de gestion/plan de contrôle.
VM/CT : règles appliquées aux machines invitées (utile, mais pas pour cette urgence).

En coulisses, Proxmox programme le pare‑feu de l’hôte via son service pve-firewall. Selon la distribution/version du noyau, les règles tombent dans nftables ou la compatibilité iptables. Lors d’un verrouillage, deux choses comptent :

Politiques par défaut : la politique d’entrée peut devenir « drop sauf autorisé » une fois le pare‑feu activé avec une posture deny par défaut.
Ports de gestion : SSH (généralement 22) et l’interface Web Proxmox (8006/TCP via pveproxy).

Le pare‑feu Proxmox n’est pas magique, mais il peut en avoir l’air quand il vous bloque et que vous regardez la console. Votre récupération dépend de la compréhension que :

Arrêter pve-firewall retire généralement les règles qu’il gère (c’est le « gros bouton rouge »).
Redémarrer pveproxy n’aide pas si le pare‑feu jette le trafic avant qu’il n’atteigne le service.
Les règles du cluster peuvent se propager et gâcher la journée sur plusieurs nœuds si vous avez utilisé le scope datacenter sans précaution.

Une idée de fiabilité paraphrasée de John Allspaw : « Les incidents résultent souvent d’un travail normal et de décisions locales qui avaient du sens à l’époque. » Traitez votre verrouillage comme un incident. Vous le réglerez plus vite et apprendrez plus.

Faits intéressants et contexte historique (pour arrêter les suppositions)

Le port 8006 est le port Web UI par défaut de Proxmox ; il n’est pas « spécial », juste facile à bloquer avec une seule mauvaise règle.
Proxmox VE est basé sur Debian, ce qui signifie que votre boîte à outils de secours est classique Linux : systemd, journalctl, iproute2, et nftables/iptables.
Le filtrage Linux a évolué : iptables a dominé pendant des années ; nftables est le remplaçant moderne, mais les couches de compatibilité peuvent rendre la sortie confuse en urgence.
Les pare‑feux stateful (conntrack) signifient que les règles « allow established/related » peuvent sauver des sessions existantes tout en bloquant les nouvelles — donc votre SSH en cours peut survivre tandis que les autres sont exclus.
Les politiques par défaut sont plus sûres que les autorisations par défaut, mais seulement si vous préautorisez la gestion. La sécurité aime « deny by default ». L’exploitation aime « ne pas briquer l’hôte ». Vous pouvez avoir les deux.
La propagation de configuration du cluster est un multiplicateur de force : elle rend les changements cohérents, et rend aussi les erreurs cohérentes.
La disponibilité de l’interface Web dépend de pveproxy et du TLS ; un blocage pare‑feu ressemble exactement à un proxy mort depuis le navigateur.
Les consoles hors‑bande (IPMI/iLO/DRAC) existent parce que les réseaux échouent et que les humains les reconfigurent mal ; « l’accès console » n’est pas un luxe.
Les abstractions UI du pare‑feu aident jusqu’à ce qu’elles cachent l’ordre réel des règles et la correspondance par interface — alors vous apprenez à la dure que « simple » a quand même des cas limites.

Accéder à une vraie console (non, pas votre onglet SSH à moitié fonctionnel)

Quand Proxmox vous verrouille, vous avez besoin d’un accès local. Options, par ordre de raison :

Console IPMI/iLO/DRAC/KVM : la meilleure pour la récupération à distance. Servez‑vous en.
Console physique : chariot de secours, écran, clavier. À l’ancienne, ça marche.
Console du fournisseur : si hébergé, utilisez leur « console VNC/série ». Acceptez les bizarreries.

Une fois dedans, évitez le thrash. Ne commencez pas à éditer au hasard tous les fichiers de conf que vous trouvez. Prenez 90 secondes pour confirmer : réseau, services, pare‑feu. Puis agissez.

Blague n°1 : Le pare‑feu n’a pas « cassé ». Il a juste développé un fort sens des frontières personnelles.

Tâches de récupération en console (commandes, sorties et décisions)

Ci‑dessous des tâches pratiques à exécuter depuis la console. Chaque tâche inclut : la commande, ce que la sortie signifie, et la décision à prendre. Ne les exécutez pas aveuglément ; suivez la logique décisionnelle.

Tâche 1 : Confirmez que vous êtes sur le bon nœud et que vous ne rêvez pas

cr0x@server:~$ hostnamectl
 Static hostname: pve-01
       Icon name: computer-server
         Chassis: server
      Machine ID: 2f5c0c0d3f3a4d44a1f8b3a2f0d0c111
         Boot ID: 7c2b3a7d2c3a4bdabf9dd0f66e1b2222
Operating System: Debian GNU/Linux 12 (bookworm)
          Kernel: Linux 6.2.16-20-pve
    Architecture: x86-64

Ce que cela signifie : Vous êtes sur le nœud que vous pensez et il tourne sur un noyau Proxmox.

Décision : Si ce n’est pas le bon nœud, arrêtez‑vous et trouvez le bon. Sinon, poursuivez.

Tâche 2 : Vérifiez le lien et l’adressage IP (vérification réseau basique)

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
enp3s0           UP             3c:ec:ef:12:34:56
vmbr0            UP             3c:ec:ef:12:34:56

cr0x@server:~$ ip -br addr show vmbr0
vmbr0            UP             10.20.30.11/24 fe80::3eec:efff:fe12:3456/64

Ce que cela signifie : Le bridge est up et possède l’IP de gestion.

Décision : Si l’interface est DOWN ou si l’IP manque, réparez d’abord le réseau (VLAN, câble, bond, configuration bridge). Les changements de pare‑feu ne corrigent pas une hôte sans IP.

Tâche 3 : Confirmez la route par défaut et que vous atteignez la passerelle

cr0x@server:~$ ip route
default via 10.20.30.1 dev vmbr0 proto kernel onlink
10.20.30.0/24 dev vmbr0 proto kernel scope link src 10.20.30.11

cr0x@server:~$ ping -c 2 10.20.30.1
PING 10.20.30.1 (10.20.30.1) 56(84) bytes of data.
64 bytes from 10.20.30.1: icmp_seq=1 ttl=64 time=0.401 ms
64 bytes from 10.20.30.1: icmp_seq=2 ttl=64 time=0.388 ms

--- 10.20.30.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1021ms
rtt min/avg/max/mdev = 0.388/0.394/0.401/0.006 ms

Ce que cela signifie : La connectivité L2/L3 de base existe. Vous pouvez probablement récupérer la gestion sans vous recâbler le cerveau.

Décision : Si le ping vers la passerelle échoue, cherchez des problèmes de trunk VLAN, ports du bridge, état du bond, ou configuration du switch en amont. Encore : ne blâmez pas le pare‑feu trop vite.

Tâche 4 : Vérifiez si les services SSH et Web UI tournent

cr0x@server:~$ systemctl status ssh --no-pager
● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled; preset: enabled)
     Active: active (running) since Thu 2025-12-26 08:14:21 UTC; 1h 22min ago
       Docs: man:sshd(8)
             man:sshd_config(5)
   Main PID: 1123 (sshd)
      Tasks: 1 (limit: 154000)
     Memory: 6.2M
        CPU: 210ms

cr0x@server:~$ systemctl status pveproxy --no-pager
● pveproxy.service - PVE API Proxy Server
     Loaded: loaded (/lib/systemd/system/pveproxy.service; enabled; preset: enabled)
     Active: active (running) since Thu 2025-12-26 08:13:58 UTC; 1h 23min ago
   Main PID: 1055 (pveproxy)
      Tasks: 4 (limit: 154000)
     Memory: 154.8M
        CPU: 1.934s

Ce que cela signifie : Les services sont up. Si vous ne pouvez toujours pas y accéder à distance, le pare‑feu est très suspect.

Décision : Si un des services est inactif/failed, réparez‑le d’abord. Un changement de pare‑feu ne fera pas revenir un daemon mort.

Tâche 5 : Vérifier que les services écoutent sur les ports attendus localement

cr0x@server:~$ ss -lntp | egrep '(:22|:8006)\s'
LISTEN 0      128          0.0.0.0:22        0.0.0.0:*    users:(("sshd",pid=1123,fd=3))
LISTEN 0      4096         0.0.0.0:8006      0.0.0.0:*    users:(("pveproxy",pid=1055,fd=6))

Ce que cela signifie : L’hôte accepte des connexions sur 22 et 8006. Si les clients distants ne peuvent pas se connecter, les paquets sont filtrés ou mal routés.

Décision : Si les ports n’écoutent pas, vérifiez les configs de service, problèmes de certificats, ou crash loops dans les logs.

Tâche 6 : Prouvez que le pare‑feu bloque avec un curl local

cr0x@server:~$ curl -kI https://127.0.0.1:8006/
HTTP/1.1 200 OK
server: pve-api-daemon/3.0
content-type: text/html; charset=UTF-8
cache-control: max-age=0

Ce que cela signifie : L’interface Web fonctionne localement. Le symptôme « down » est un problème de chemin réseau ou de pare‑feu, pas de pveproxy lui‑même.

Décision : Passez à l’inspection et au rollback du pare‑feu.

Tâche 7 : Vérifiez l’activation du pare‑feu Proxmox en runtime (service + état)

cr0x@server:~$ systemctl status pve-firewall --no-pager
● pve-firewall.service - Proxmox VE firewall
     Loaded: loaded (/lib/systemd/system/pve-firewall.service; enabled; preset: enabled)
     Active: active (running) since Thu 2025-12-26 09:01:12 UTC; 36min ago
   Main PID: 2289 (pve-firewall)
      Tasks: 1 (limit: 154000)
     Memory: 19.7M
        CPU: 4.311s

Ce que cela signifie : Le pare‑feu Proxmox est actif et gère des règles.

Décision : Si vous êtes verrouillé et que vous avez besoin d’une restauration rapide, arrêter ce service est un mouvement d’urgence légitime. Si vous préférez une restauration partielle, éditez les règles à la place.

Tâche 8 : Consultez les logs du pare‑feu pour les drops (ça évite de deviner)

cr0x@server:~$ journalctl -u pve-firewall --since "30 min ago" --no-pager | tail -n 20
Dec 26 09:19:10 pve-01 pve-firewall[2289]: status update OK
Dec 26 09:19:10 pve-01 pve-firewall[2289]: compile new ruleset
Dec 26 09:19:11 pve-01 pve-firewall[2289]: firewall update successful

cr0x@server:~$ journalctl -k --since "30 min ago" --no-pager | egrep -i 'PVEFW|DROP|REJECT' | tail -n 10
Dec 26 09:28:03 pve-01 kernel: PVEFW-DROP-IN: IN=vmbr0 OUT= MAC=3c:ec:ef:12:34:56 SRC=10.20.30.50 DST=10.20.30.11 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=22222 DF PROTO=TCP SPT=51234 DPT=8006 WINDOW=64240 SYN
Dec 26 09:28:08 pve-01 kernel: PVEFW-DROP-IN: IN=vmbr0 OUT= MAC=3c:ec:ef:12:34:56 SRC=10.20.30.50 DST=10.20.30.11 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=22223 DF PROTO=TCP SPT=51235 DPT=22 WINDOW=64240 SYN

Ce que cela signifie : Les logs noyau montrent que votre poste d’administration (10.20.30.50) est droppé sur les ports 8006 et 22. C’est une preuve évidente, pas une interprétation.

Décision : Appliquez une autorisation d’urgence (préférable si vous pouvez être précis) ou arrêtez pve-firewall (plus rapide).

Tâche 9 (le plus rapide) : Arrêtez le pare‑feu Proxmox pour restaurer l’accès immédiatement

cr0x@server:~$ systemctl stop pve-firewall

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

Ce que cela signifie : L’ensemble de règles géré par Proxmox devrait être retiré. L’accès distant devrait revenir si le pare‑feu était le bloqueur.

Décision : Essayez SSH/Web UI depuis votre machine d’administration maintenant. Si l’accès revient, vous avez confirmé la cause racine. Ensuite : corrigez les règles correctement, puis réactivez le pare‑feu.

Tâche 10 : Si l’accès ne revient toujours pas, inspectez nftables/iptables directement

Parfois d’autres outils, scripts personnalisés, ou jeux de règles résiduels restent. Vérifiez ce qui est réellement chargé.

cr0x@server:~$ nft list ruleset | head -n 40
table inet filter {
	chain input {
		type filter hook input priority filter; policy accept;
		ct state established,related accept
		iif "lo" accept
	}
}

Ce que cela signifie : Un jeu de règles minimal nftables avec policy accept. Si c’est ce que vous voyez, le filtrage par pare‑feu a probablement lieu ailleurs qu’au niveau nft.

Décision : Si vous voyez policy drop et aucune règle d’autorisation pour vos ports de gestion, vous pouvez ajouter une règle d’autorisation temporaire (voir tâche suivante). Si nft est vide mais que vous suspectez iptables, vérifiez iptables aussi.

cr0x@server:~$ iptables -S | head -n 30
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

Ce que cela signifie : iptables est permissif. Si vous êtes toujours verrouillé, suspectez le routage, rp_filter, des ACL en amont, ou une mauvaise IP.

Décision : Continuez avec des tests de connectivité et des contrôles en amont.

Tâche 11 (chirurgicale) : Autoriser temporairement SSH et 8006 depuis votre IP d’administration avec nftables

Si vous devez conserver une posture default‑drop pendant la récupération, ajoutez une autorisation étroite pour votre poste ou bastion. Cela suppose que nftables est actif sur votre nœud.

cr0x@server:~$ nft add table inet emergency
cr0x@server:~$ nft 'add chain inet emergency input { type filter hook input priority -50; policy accept; }'
cr0x@server:~$ nft add rule inet emergency input ip saddr 10.20.30.50 tcp dport {22,8006} accept
cr0x@server:~$ nft list table inet emergency
table inet emergency {
	chain input {
		type filter hook input priority -50; policy accept;
		ip saddr 10.20.30.50 tcp dport { 22, 8006 } accept
	}
}

Ce que cela signifie : Vous avez créé une chaîne « emergency » à haute priorité qui accepte le trafic de gestion depuis une IP avant que d’autres chaînes ne puissent le dropper.

Décision : Utilisez ceci pour revenir à distance, puis corrigez correctement les règles Proxmox. Supprimez la table emergency ensuite ; ne laissez pas de bandeau de scène de crime en production.

Tâche 12 : Vérifiez les fichiers de configuration du pare‑feu Proxmox (trouvez la règle qui vous a fait mal)

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

cr0x@server:~$ sed -n '1,120p' /etc/pve/firewall/cluster.fw
[OPTIONS]
enable: 1
policy_in: DROP
policy_out: ACCEPT

[RULES]
IN DROP -p tcp --dport 8006 -log nolog

Ce que cela signifie : La politique d’entrée du cluster est DROP et il y a un DROP explicite pour 8006. Voilà comment vous avez briqué l’UI — poliment et à grande échelle.

Décision : Retirez la mauvaise règle DROP, ajoutez une règle d’autorisation pour votre sous‑réseau d’administration, et conservez policy_in DROP si c’est votre posture de sécurité. Ne refusez simplement pas votre propre plan de contrôle.

Tâche 13 : Ajouter une règle d’autorisation correcte dans le pare‑feu Proxmox (correctif permanent privilégié)

Exemple : autoriser la gestion depuis un sous‑réseau d’administration vers le nœud.

cr0x@server:~$ sed -n '1,120p' /etc/pve/firewall/pve-01.fw
[OPTIONS]
enable: 1
policy_in: DROP
policy_out: ACCEPT

[RULES]
IN ACCEPT -source 10.20.30.0/24 -p tcp -dport 22 -log nolog
IN ACCEPT -source 10.20.30.0/24 -p tcp -dport 8006 -log nolog
IN ACCEPT -p icmp -log nolog

Ce que cela signifie : Le nœud a des autorisations explicites pour SSH et l’UI Web depuis votre sous‑réseau d’administration, tout en continuant à dropper par défaut tout le reste entrant.

Décision : Si votre sous‑réseau d’administration n’est pas fiable, remplacez‑le par l’IP du bastion ou la plage VPN. « 0.0.0.0/0 peut gérer mon hyperviseur » n’est pas une stratégie de sécurité.

Tâche 14 : Recharger le pare‑feu Proxmox et vérifier la compilation

cr0x@server:~$ systemctl start pve-firewall
cr0x@server:~$ systemctl status pve-firewall --no-pager
● pve-firewall.service - Proxmox VE firewall
     Loaded: loaded (/lib/systemd/system/pve-firewall.service; enabled; preset: enabled)
     Active: active (running) since Thu 2025-12-26 10:02:13 UTC; 2s ago
   Main PID: 9912 (pve-firewall)

cr0x@server:~$ pve-firewall compile
status: ok

Ce que cela signifie : Le service est actif ; les règles se compilent sans erreur.

Décision : Si la compilation échoue, le pare‑feu peut revenir en arrière ou s’appliquer partiellement. Corrigez la syntaxe avant de lui faire confiance. Un pare‑feu « à moitié appliqué » est source de hantise.

Tâche 15 : Validez depuis l’hôte : est‑ce que les paquets sont encore droppés ?

Vous ne pouvez pas parfaitement simuler l’accès distant depuis la console locale, mais vous pouvez vérifier si le noyau journalise encore des drops pour votre source d’administration.

cr0x@server:~$ journalctl -k --since "5 min ago" --no-pager | egrep -i 'PVEFW-DROP-IN' | tail -n 5

Ce que cela signifie : S’il n’y a pas de nouveaux drops pendant que vous tentez de vous connecter à distance, vous avez probablement résolu le problème. Si les drops persistent, votre règle d’autorisation ne matche pas (mauvaise plage source, interface, protocole ou scope).

Décision : Si les drops persistent, vérifiez l’ordre et la portée des règles (datacenter vs nœud). Vérifiez aussi si vous touchez l’hôte depuis une IP différente que prévue (NAT, VPN, jump host).

Tâche 16 : Confirmer le chemin distant avec tcpdump (quand vous avez besoin d’une preuve, pas d’impressions)

cr0x@server:~$ tcpdump -ni vmbr0 tcp port 8006 or tcp port 22 -c 10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vmbr0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:06:41.112233 IP 10.20.30.50.51234 > 10.20.30.11.8006: Flags [S], seq 1234567890, win 64240, options [mss 1460,sackOK,TS val 111 ecr 0,nop,wscale 7], length 0
10:06:41.112455 IP 10.20.30.11.8006 > 10.20.30.50.51234: Flags [S.], seq 987654321, ack 1234567891, win 65160, options [mss 1460,sackOK,TS val 222 ecr 111,nop,wscale 7], length 0

Ce que cela signifie : Vous voyez SYN et SYN‑ACK. C’est de la connectivité. Si le SYN arrive mais pas le SYN‑ACK, l’hôte droppe ou n’écoute pas.

Décision : SYN seul signifie généralement drop pare‑feu. SYN+SYN‑ACK signifie que vous êtes revenu ; tout problème restant est probablement lié au TLS/certificat/navigateur ou à un reverse proxy.

Tâche 17 : Vérifiez si vous vous êtes accidentellement bloqué par interface (vmbr0 vs une sous‑interface VLAN)

cr0x@server:~$ ip -d link show vmbr0 | head -n 12
4: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 3c:ec:ef:12:34:56 brd ff:ff:ff:ff:ff:ff
    bridge forward_delay 1500 hello_time 200 max_age 2000 ageing_time 30000 stp_state 0 priority 32768 vlan_filtering 1 vlan_default_pvid 1 vlan_protocol 802.1Q

Ce que cela signifie : Le filtrage VLAN est activé sur le bridge. Si vos tags VLAN de gestion ou hypothèses PVID sont erronés, le trafic ne parvient peut‑être même pas à toucher l’hôte comme vous le pensez.

Décision : Si vous avez récemment modifié VLANs/bridge en même temps que le pare‑feu, isolez : confirmez L2/VLAN d’abord, puis le pare‑feu.

Tâche 18 : Vérifiez la santé du système de fichiers du cluster (parce que /etc/pve est spécial)

cr0x@server:~$ pvecm status 2>/dev/null | head -n 15
Cluster information
-------------------
Name:             corp-cluster
Config Version:   42
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Thu Dec 26 10:08:12 2025
Quorum:           Yes

Ce que cela signifie : Si vous êtes en cluster, /etc/pve est un système de fichiers cluster. Des problèmes de quorum peuvent rendre les modifications de configuration compliquées ou non propagées.

Décision : S’il n’y a pas de quorum, évitez de faire des hypothèses « globales ». Préférez la restauration d’accès locale au nœud et procédez avec prudence.

Blague n°2 : Rien n’enseigne le « change control » comme une introduction physique à la salle serveurs à 2h du matin.

Trois mini‑histoires d’entreprise (douleur, regret et un héros discret)

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

Une entreprise de taille moyenne utilisait Proxmox pour des charges internes : runners CI, quelques bases de données, et un cluster de VM « temporaires » qui avaient vécu pendant des années. Un nouveau responsable sécurité a demandé « default deny inbound » sur les hyperviseurs. Raisonnable. L’équipe a accepté — puis a fait la partie dangereuse : elle a supposé que leur sous‑réseau VPN était la seule source de trafic de gestion.

En réalité, l’équipe d’exploitation utilisait un bastion sur un autre sous‑réseau pour la maintenance. Le bastion avait été mis en place lors d’une refonte réseau et était devenu silencieusement le chemin d’administration par défaut. Le changement de pare‑feu autorisait SSH et 8006 depuis la plage VPN, et dropait tout le reste.

Au début, rien ne semblait cassé. Les personnes déjà connectées via SSH continuaient de travailler parce que les règles stateful laissaient passer les connexions établies. Cela faisait paraître le changement sûr. Puis le bastion a été rebooté pour des mises à jour noyau. Au redémarrage, il ne pouvait plus SSH dans les nœuds. L’interface Web était aussi morte. Soudain, le déploiement « default deny » semblait être une panne.

La correction fut simple : console sur un nœud, stop pve-firewall, ajouter une autorisation pour le sous‑réseau du bastion, start pve-firewall, tester depuis le bastion et le VPN. La leçon n’était pas « ne pas faire default deny ». La leçon était que les hypothèses sur les chemins de gestion sont des mensonges tant qu’on ne les inventorie pas.

Après l’incident, ils ont rédigé un « contrat plan de gestion » d’une page : quels sous‑réseaux peuvent accéder aux hyperviseurs, quels ports, et comment tester depuis chaque chemin avant d’activer DROP. C’était ennuyeux. Ça a marché.

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

Une autre organisation avait pour habitude « d’optimiser » les règles pour les garder propres. Un ingénieur a décidé de consolider les règles au scope datacenter pour que chaque nœud se comporte de la même façon. Argument : moins d’exceptions par nœud, moins de snowflakes, conformité plus facile. En principe, OK.

Le retour de bâton est venu de l’hétérogénéité. Certains nœuds avaient la gestion sur vmbr0 non tagué ; d’autres utilisaient un VLAN taggé sur vmbr0.20. Les règles consolidées incluaient des correspondances d’interface correctes pour la moitié du parc et erronées pour l’autre moitié. Les nœuds affectés ne matchaient pas les règles d’autorisation, donc la policy par défaut DROP s’appliquait.

Ils ont perdu l’accès à plusieurs nœuds à la fois, ce qui est le genre de panne qui fait poser des questions du type « Pourquoi ne peut‑on pas simplement se connecter ? ». L’équipe a dû utiliser des consoles hors‑bande pour récupérer, hôte par hôte, pendant que le reste de l’entreprise regardait une page de statut non engageante.

Ce qui a empiré la situation : comme les règles étaient cluster‑wide, « corriger vite » signifiait pousser un autre changement cluster‑wide, que l’équipe hésitait à faire faute de certitude sur le comportement des règles. Ils ont fini par stopper pve-firewall sur les nœuds verrouillés, restaurer l’accès, puis repenser les règles autour de groupes de gestion : une allowlist basée sur les réseaux source et les ports sans hypothèses fragiles par interface.

Le point : la consolidation n’est pas automatiquement une simplification. Si l’environnement n’est pas uniforme, une « optimisation globale » est parfois simplement un rayon d’explosion global.

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

Une société financière exploitait un cluster Proxmox pour des environnements de test — toujours importants, toujours liés à des délais réels. Ils avaient une règle stricte : tout changement de pare‑feu devait inclure un chemin « break glass » pré‑stagé, testé depuis un autre réseau.

Ce chemin était volontairement ennuyeux : un jump host d’administration dédié avec une IP fixe, autorisé à atteindre SSH et 8006 sur tous les hyperviseurs, et surveillé. Ils avaient aussi IPMI activé et documenté, avec les identifiants stockés dans un coffre contrôlé. Personne n’aimait le maintenir. Ce n’était pas glamour.

Un après‑midi, quelqu’un a accidentellement appliqué une règle datacenter qui dropait tout le TCP entrant sauf quelques ports applicatifs. C’était une erreur d’UI honnête : l’ingénieur pensait éditer une politique VM, pas la politique datacenter. En quelques secondes, la plupart des accès de gestion ont disparu.

L’équipe n’a pas paniqué. Ils ont utilisé le jump host, qui avait encore accès par conception, pour se connecter aux nœuds et annuler la règle. Pas d’acrobaties console. Pas de devinettes. Le postmortem fut court et sans romantisme : améliorer les garde‑fous UI, ajouter des confirmations pour les changements datacenter, et garder le jump host « ennuyeux » surveillé.

Parfois le meilleur choix d’ingénierie est d’être volontairement inintéressant.

Erreurs courantes : symptôme → cause racine → correction

Cette section est celle où vous faites correspondre ce que vous voyez à ce qui se passe réellement. La reconnaissance de motifs rapide vaut mieux que la souffrance créative.

1) Le navigateur met un timeout sur le port 8006, mais curl local fonctionne

Symptôme : UI Web inaccessible à distance, mais curl -kI https://127.0.0.1:8006/ renvoie 200.
Cause racine : Pare‑feu qui droppe le TCP/8006 entrant ou ACL en amont.
Correction : Stoppez pve-firewall pour restaurer l’accès, puis ajoutez des règles explicites autorisant TCP/8006 depuis les sources d’administration et rechargez.

2) SSH fonctionnait pour une personne, puis a cessé quand elle s’est déconnectée

Symptôme : La session SSH existante a survécu ; les nouvelles sessions SSH échouent.
Cause racine : Autorisation stateful pour les connexions établies, mais le nouveau TCP/22 entrant est droppé.
Correction : Ajoutez une autorisation explicite pour TCP/22 depuis les sources d’administration ; ne comptez pas sur la chance du conntrack.

3) Un seul nœud est verrouillé ; les autres vont bien

Symptôme : Le cluster est majoritairement accessible ; un nœud est injoignable pour SSH/UI.
Cause racine : Pare‑feu au niveau nœud activé avec une politique plus stricte, mismatch d’interface, ou faute de frappe dans une règle spécifique au nœud.
Correction : Vérifiez /etc/pve/firewall/pve-XX.fw pour enable et policy ; comparez à un nœud fonctionnel ; redémarrez pve-firewall après correction.

4) Tout est verrouillé juste après une édition du pare‑feu datacenter

Symptôme : Plusieurs nœuds deviennent inaccessibles presque simultanément.
Cause racine : Règle cluster‑wide (datacenter) qui a dropé les ports de gestion ou changement de policy par défaut en DROP sans allowlist.
Correction : Console sur un nœud, stop pve-firewall, éditez /etc/pve/firewall/cluster.fw pour autoriser la gestion, démarrez le pare‑feu, validez, puis répétez si nécessaire.

5) L’UI Web fonctionne sur le LAN mais pas via le VPN

Symptôme : Le sous‑réseau local atteint 8006 ; les utilisateurs VPN non.
Cause racine : Règles d’autorisation scoping limitées à un seul sous‑réseau ; NAT VPN modifiant l’IP source ; ou problèmes de MTU faisant croire à un pare‑feu.
Correction : Confirmez l’IP source VPN vue par Proxmox via les logs du pare‑feu ou tcpdump ; ajustez la règle d’autorisation en conséquence ; si SYN‑ACK visible mais UI encore défaillante, vérifiez MTU/TLS plutôt que le pare‑feu.

6) Arrêter pve-firewall ne restaure pas l’accès

Symptôme : systemctl stop pve-firewall mais SSH/UI toujours inaccessibles.
Cause racine : Règles appliquées par nftables/iptables non gérées par pve-firewall, pare‑feu/ACL en amont, route incorrecte, ou mauvaise IP.
Correction : Inspectez nft list ruleset et iptables -S, vérifiez IP/route, lancez tcpdump pour voir si le SYN atteint l’hôte, et contrôlez la politique réseau en amont.

7) Vous avez autorisé 8006 mais ne pouvez toujours pas vous connecter

Symptôme : Les connexions TCP réussissent mais la connexion UI échoue ou se charge partiellement.
Cause racine : Pas le pare‑feu : peut être pveproxy, dérèglement horaire, problème d’auth backend, ou mismatch certificat/hostname (surtout derrière des proxies).
Correction : Vérifiez systemctl status pveproxy, inspectez journalctl -u pveproxy, confirmez la synchronisation temporelle, et testez la connexion locale d’abord.

8) Vous avez édité /etc/pve/firewall mais rien ne change

Symptôme : Les changements ne s’appliquent pas, les règles semblent inchangées.
Cause racine : Système de fichiers cluster non sain (problèmes de quorum), ou vous avez édité le mauvais scope.
Correction : Vérifiez pvecm status pour le quorum ; assurez‑vous d’avoir édité le bon fichier (cluster.fw vs fichier nœud *.fw) ; redémarrez pve-firewall et confirmez le statut de compilation.

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

Étapes d’urgence (restaurer l’accès en moins de 10 minutes)

Ouvrir l’accès console (IPMI/KVM/console fournisseur).
Confirmer IP et route :
- ip -br addr montre l’IP de gestion correcte.
- ip route montre la route par défaut.
Confirmer les services :
- systemctl status ssh et systemctl status pveproxy.
- ss -lntp | egrep '(:22|:8006)'.
Confirmer les drops du pare‑feu (optionnel mais rapide) :
- journalctl -k | egrep -i 'PVEFW|DROP|REJECT'.
Choisir un mode de récupération :
- Le plus rapide : systemctl stop pve-firewall.
- Plus contrôlé : ajoutez une autorisation étroite pour votre IP admin (chaîne nft emergency) ou éditez /etc/pve/firewall/*.fw.
Vérifier depuis l’extérieur : tester SSH et https://node:8006 depuis un hôte admin fiable.
Corriger la règle réelle : supprimer le deny, ajouter la allowlist correcte, recharger le pare‑feu (systemctl start pve-firewall et pve-firewall compile).
Supprimer les règles d’urgence nft temporaires si vous les avez créées :
- nft delete table inet emergency

Checklist de stabilisation (après restauration)

Identifier le scope : était‑ce Datacenter, Nœud, ou VM/CT firewall ?
Confirmer les politiques : policy_in et policy_out à chaque scope.
Définir les sources de gestion : sous‑réseau VPN, IP du jump host, laptops d’astreinte, NAT egress du bureau — notez la liste.
Mettre en place une allowlist de gestion :
- Autoriser TCP/22 et TCP/8006 depuis cette liste.
- Autoriser ICMP depuis cette liste (optionnel, mais utile opérationnellement).
Tester depuis chaque chemin : VPN, jump host, réseau bureau, etc. Ne pas supposer.
Activer la journalisation des drops uniquement où nécessaire ; trop de logs masque les vrais drops.
Documenter le break‑glass : où est la console, comment y accéder, et qui peut.

Prévention : rendre les verrouillages ennuyeux

Une fois l’accès rétabli, faites la chose responsable : empêcher la récidive. Pas avec de l’espoir. Avec du design.

1) Séparer le « plan de gestion » du « reste »

Si votre gestion hyperviseur partage le même LAN et les mêmes politiques que le trafic invité, vous invitez les ennuis. Meilleurs patterns :

VLAN/subnet de gestion dédié avec ingress contrôlé.
VPN d’administration qui vous place dans ce subnet (ou NAT vers une IP d’egress connue).
Bastion avec IP stable et authentification forte. Autoriser la gestion seulement depuis lui si possible.

2) Gardez votre « allowlist pour SSH et 8006 » explicite et locale

Vous pouvez définir policy_in DROP globalement, mais ne comptez pas sur une règle datacenter fragile pour préserver votre seul chemin d’accès. Utilisez des règles nœud pour l’allowlist de gestion, surtout si les nœuds diffèrent (interfaces, tags VLAN, subnets).

3) Utilisez la « règle des deux personnes » pour les changements datacenter

Le scope datacenter est un rayon d’explosion cluster. Traitez‑le comme une modification de schéma de base de données en production : revue, vérification de la portée, et rollback.

4) Testez avec une nouvelle connexion, pas votre session chanceuse existante

Les pare‑feux stateful peuvent vous tromper. Validez toujours avec une nouvelle connexion SSH depuis un second terminal, ou depuis un hôte différent, avant de déclarer la réussite.

5) Préférez des changements temporaires étroits en incident

Quand vous êtes en panne, « arrêter temporairement pve-firewall » est acceptable parce que c’est réversible et rapide. Mais ne laissez pas le pare‑feu désactivé pendant des jours. C’est comme ça que le temporaire devient permanent, et le permanent devient politique.

6) Construisez un workflow « break‑glass » que vous pouvez exécuter à moitié endormi

Au minimum :

Accès hors‑bande vérifié trimestriellement.
Procédure de login console documentée.
Une IP/plage admin connue à autoriser.
Un snippet pré‑rédigé pour les règles nœud autorisant TCP/22 et TCP/8006.

FAQ

1) Dois‑je simplement désactiver le pare‑feu Proxmox définitivement ?

Non. Désactivez‑le brièvement pour récupérer, puis corrigez la politique. Les hyperviseurs sont des systèmes privilégiés ; les laisser en accès libre, c’est s’inviter à un audit sévère.

2) Quelle est la commande la plus rapide et sûre pour rétablir l’accès ?

Depuis la console : systemctl stop pve-firewall. Si les services tournent et le réseau est correct, cela restaure généralement SSH et l’interface Web immédiatement.

3) Pourquoi l’UI Web utilise le port 8006, puis‑je le changer ?

8006 est le port par défaut de pveproxy. Vous pouvez modifier l’exposition via des reverse proxies et la politique réseau, mais changer le port lui‑même crée rarement moins de friction opérationnelle pendant les incidents.

4) J’ai stoppé pve-firewall mais je suis toujours verrouillé. Et maintenant ?

Prouvez si les paquets atteignent l’hôte. Utilisez tcpdump -ni vmbr0 tcp port 22 en tentant une connexion. Si aucun SYN n’arrive, c’est en amont (routage, VLAN, ACL). Si le SYN arrive mais pas de SYN‑ACK, c’est du filtrage local ou un problème de service/écoute.

5) Est‑il préférable de corriger les règles via l’UI ou en éditant /etc/pve/firewall/*.fw ?

Pendant une panne, éditez ce qui est le plus rapide et le moins sujet aux erreurs pour vous. L’UI est agréable mais peut être indisponible lors d’un verrouillage. L’édition console est acceptable ; validez avec pve-firewall compile et redémarrez le service.

6) Quelle règle doit toujours exister pour éviter le verrouillage de gestion ?

Une autorisation explicite pour TCP/22 et TCP/8006 depuis une source de gestion contrôlée (IP du bastion ou sous‑réseau admin), au niveau nœud si votre environnement est hétérogène.

7) Les règles VM/CT peuvent‑elles me verrouiller hors de l’hôte ?

Pas directement. Les règles VM/CT s’appliquent aux interfaces invitées. Les verrouillages d’hôte viennent généralement des réglages pare‑feu datacenter/nœud ou d’autres outils de filtrage au niveau hôte.

8) Comment savoir si Proxmox utilise nftables ou iptables ?

Vérifiez ce qui a des règles chargées : nft list ruleset et iptables -S. Sur les systèmes Debian modernes, nftables est courant, parfois avec une compatibilité iptables. En cas de panne, fiez‑vous à ce qui est réellement présent, pas à vos souvenirs de l’an dernier.

9) Et IPv6 — cela peut‑il provoquer des « demi‑verrouillages » ?

Oui. Si les clients préfèrent IPv6 et que vos règles n’autorisent que l’IPv4 (ou vice versa), l’accès sera incohérent. Vérifiez ip -br addr pour des adresses IPv6 et assurez‑vous que votre politique correspond à la réalité.

10) Si je suis en cluster, puis‑je corriger depuis n’importe quel nœud ?

Peut‑être. Si le verrouillage affecte tous les nœuds, vous aurez besoin d’un accès console à au moins un d’entre eux. Aussi, si le cluster n’a pas de quorum, le comportement de /etc/pve peut être contraint. En urgence, restaurez l’accès par nœud d’abord, puis réconciliez la config du cluster une fois stable.

Conclusion : prochaines étapes à réaliser aujourd’hui

Se faire verrouiller par des règles de pare‑feu Proxmox est courant parce que l’UI propre masque un outil tranchant. La récupération est simple : confirmez le réseau, confirmez les services, confirmez les drops pare‑feu, puis soit stoppez pve-firewall, soit ajoutez une autorisation étroite pour retrouver l’accès. Ensuite, corrigez les règles proprement avec des allowlists de gestion explicites et le scope adapté.

Prochaines étapes qui rapportent de l’argent :

Créez une allowlist de gestion au niveau nœud pour TCP/22 et TCP/8006 depuis un bastion ou un sous‑réseau admin.
Vérifiez que l’accès hors‑bande console fonctionne avant que le prochain incident ne vous force à découvrir qu’il ne fonctionne pas.
Ajoutez un test pré‑changement simple : « Une nouvelle connexion SSH et une nouvelle connexion 8006 réussissent‑elles depuis chaque chemin admin ? »
Conservez votre plan de rollback sous forme d’une commande à taper depuis la console sans réfléchir : stop firewall, restaurer l’accès, puis corriger la politique.