Corregir pve-firewall.service fallado en Proxmox sin bloquearte

noviembre 14, 2025 • febrero 3, 2026 • Lectura: 25 min • Views: 11

¿Te fue útil?

Tu host Proxmox arranca, las VM están encendidas, el clúster parece bien—luego la interfaz web empieza a fallar por tiempo de espera, SSH se vuelve “irregular” y systemd lanza la pequeña bomba: pve-firewall.service failed. El instinto es reiniciarlo hasta que se comporte. Ese instinto es como terminas yendo al centro de datos a pie o suplicando a alguien con acceso al console.

Este es el camino seguro: mantén una cuerda de gestión, encuentra la regla/configuración exacta que falló y vuelve a poner en marcha el firewall sin convertir el nodo en un autodenegador de servicio.

Qué hace realmente pve-firewall (y por qué falla)

El firewall de Proxmox VE (PVE) no es “solo iptables”. Es un generador y orquestador de reglas que lee la configuración de varios lugares (datacenter, nodo, nivel VM), la compila en conjuntos de reglas y luego las instala en el host y, opcionalmente, en bridges/dispositivos tap para invitados. Cuando funciona, es tranquilamente aburrido. Cuando falla, obtienes dos tipos de problemas:

Servicio que no arranca: las reglas nunca se instalan, o quedan reglas parciales, dependiendo de dónde murió.
Servicio arranca pero tu acceso muere: las reglas se instalan correctamente—pero tus suposiciones sobre redes de gestión, puertos de clúster o filtrado en bridges eran incorrectas.

systemd es contundente: si los scripts auxiliares salen con código distinto de cero, pve-firewall.service se marca como fallado. Ese código no cero suele ser un problema sintáctico (definición de regla mala), una dependencia ausente (módulos de kernel / backends xtables), o un conflicto (tu propio gestor de nftables/iptables interfiriendo con las reglas de PVE).

Hay una razón por la que los operadores experimentados se ponen tensos al reiniciar el firewall: el firewall es uno de los pocos componentes que puede romper la única vía para arreglar el firewall. Es un problema muy característico de ingeniería.

Un máximo de confiabilidad para tener en mente—idea parafraseada de Gene Kim (autor de DevOps): “Los cambios pequeños y seguros ganan a las soluciones heroicas bajo presión.” Ese es todo el enfoque aquí: aislar, validar y luego aplicar de forma que se preserve el acceso.

Guía rápida de diagnóstico

Si estás en medio de un incidente, no empieces por “afinar reglas”. Empieza por encontrar qué está roto y si todavía tienes una cuerda de seguridad.

Primero: confirma las rutas de acceso

¿Tienes consola fuera de banda (IPMI/iDRAC/iLO) o acceso físico?
¿Tienes una sesión SSH existente que puedas mantener abierta?
¿Puedes abrir una segunda sesión desde otra red (VPN, bastión) como respaldo?

Segundo: lee el fallo, no adivines

systemctl status pve-firewall para la última línea de error.
journalctl -u pve-firewall -b para el registro completo.
Revisa /etc/pve/firewall/ para problemas de sintaxis si los logs mencionan parsing.

Tercero: determina el backend del firewall y conflictos

iptables --version y update-alternatives --display iptables
¿Está corriendo nftables? ¿Está instalado ufw? ¿Está instalado firewalld?

Cuarto: aísla lo que cambió

¿Actualizaciones recientes? ¿Kernel? ¿Versión de PVE?
¿Ediciones recientes en las pestañas de Firewall de Datacenter/Nodo/VM?
¿Alguna automatización tocando /etc/network/interfaces o /etc/pve?

Si haces solo una cosa de esta guía: extrae logs y valida configs antes de reiniciar repetidamente. Los reinicios repetidos convierten un bug determinista en una interrupción basada en tiempo.

Seguridad primero: no te bloquees

Cuando el firewall está roto, tu objetivo no es “máxima seguridad”. Tu objetivo es “restaurar conectividad controlada” para que puedas terminar la reparación. Eso significa:

Mantén al menos una sesión root abierta (SSH o consola) mientras pruebas cambios.
Prefiere acceso por consola si está disponible. Es inmune a tus propias reglas de firewall.
Escalona cambios y usa rollback temporizado cuando sea posible.
No recargues bridges de red a la ligera a menos que entiendas cómo tu nodo transporta el tráfico de gestión.

Broma corta #1: Reiniciar un firewall es como cambiar una llanta en la autopista—hazlo, pero no te sorprendas si se pone emocionante.

Dos patrones pragmáticos de seguridad:

Patrón A: “Dos sesiones y un temporizador”

Abre dos sesiones root. En la sesión #2, programa un rollback (deshabilitar firewall o restaurar configuración conocida) en 2–5 minutos. En la sesión #1, intenta la corrección. Si pierdes acceso, espera que el rollback te salve.

Patrón B: “Consola primero para pasos riesgosos”

Si tienes IPMI/iLO/etc., realiza operaciones riesgosas (reinicio de servicio, aplicar reglas nuevas, cambiar el filtrado de bridges) desde la consola. Así tu transporte no depende de lo que estás modificando.

Tareas prácticas (comandos, salidas, decisiones)

A continuación hay tareas prácticas que puedes ejecutar en un nodo Proxmox. Cada una incluye lo que la salida suele significar y la decisión que tomarás después. Los comandos son intencionalmente conservadores: recopilar hechos, validar la configuración y luego aplicar cambios con control.

Tarea 1: Confirma el estado del servicio y la última línea de error

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.

Qué significa: Tienes un error de parsing; normalmente es una falta de tipeo o una línea de regla inválida en un archivo .fw.

Decisión: No reinicies otra vez. Ve a inspeccionar el archivo y el número de línea referenciados.

Tarea 2: Extrae el registro completo del arranque actual

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

Qué significa: El servicio arrancó el proceso, leyó la configuración y luego abortó limpiamente tras el error. El cleanup sugiere que intentó eliminar reglas parciales.

Decisión: Arregla la configuración. Si el cleanup no ocurrió, puede que necesites vaciar reglas rotas más tarde.

Tarea 3: Verifica si el firewall está habilitado en todos los niveles

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

Qué significa: El firewall está habilitado globalmente y en el nodo; actualmente está detenido por la falla.

Decisión: Si necesitas un movimiento temporal para «recuperarme», deshabilita a nivel datacenter/nodo (con la consola lista). De lo contrario, procede a arreglar y reiniciar.

Tarea 4: Comprueba la salud del sistema de archivos del clúster (porque ahí viven las configs)

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

Qué significa: El clúster tiene quórum; /etc/pve debería ser escribible y consistente.

Decisión: Si no hay quórum, puede que veas configs obsoletas/partiales y las ediciones no se apliquen. Arregla primero quórum/almacenamiento.

Tarea 5: Encuentra la línea errónea rápidamente

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

Qué significa: --dport abc es inválido. El parser del firewall de PVE lo rechaza.

Decisión: Reemplázalo por un puerto numérico o un servicio/alias válido si tu estilo de regla lo soporta. Luego vuelve a probar.

Tarea 6: Valida que no rompiste una referencia de alias/grupo

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

Qué significa: Tu grupo/alias existe. Si tu regla referencia +mgmt, debería resolverse.

Decisión: Si el grupo/alias falta o está mal escrito, arregla eso en lugar de la regla en sí.

Tarea 7: Pensamiento de ejecución en seco: verifica puertos que no debes romper

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))

Qué significa: Los servicios de gestión están escuchando. El firewall debe permitir que tus redes de gestión lleguen al menos a 22/8006.

Decisión: Si no estás explícitamente permitiendo tus subredes de origen, no reinicies el firewall todavía. Añade primero una regla de permitir.

Tarea 8: Comprueba si estás en backend nftables o iptables legacy

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

Qué significa: iptables está usando el backend nf_tables. Esto está bien, pero cambia cómo se comportan los conflictos y cómo aparecen las reglas.

Decisión: Si tienes scripts que esperan salida legacy, pueden detectar mal las reglas y “arreglar” cosas incorrectamente. Audita la automatización.

Tarea 9: Busca gestores de firewall en conflicto

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

Qué significa: Ningún servicio competidor está gestionando activamente reglas.

Decisión: Si alguno está activo, desactívalo o decide explícitamente quién posee las reglas. Dos cocineros, una sopa, mismo final.

Tarea 10: Confirma ajustes de filtrado en bridge (palanca común de bloqueo)

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

Qué significa: El tráfico puenteado pasa por reglas iptables/nft. Con PVE firewall habilitado, esto es esperado para el filtrado de VM.

Decisión: Si no pretendías filtrar tráfico de bridge, podrías estar filtrando tu propia ruta de gestión (dependiendo de la topología). Valida cómo llega la gestión al host (NIC directa vs bridge).

Tarea 11: Comprueba si falta una dependencia de módulo del kernel

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

Qué significa: Las piezas comunes están presentes. Si no ves nada relevante, puede existir un problema mínimo de kernel/módulos.

Decisión: Si faltan módulos tras una actualización de kernel, reinicia en el kernel correcto o reinstala los paquetes coincidentes.

Tarea 12: Programa un rollback de forma segura antes de intentar reiniciar

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

Qué significa: Has programado un “switch de muerto”. Si te bloqueas, el host detendrá el servicio PVE firewall dentro de poco.

Decisión: Procede con el reinicio/pruebas. Si todo va bien, elimina el job: atrm 7.

Tarea 13: Reinicia el firewall y confirma que permanece activo

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

Qué significa: El servicio arrancó correctamente.

Decisión: Valida de inmediato que todavía puedes alcanzar SSH y la GUI desde tu red de gestión. Luego cancela el job de rollback.

Tarea 14: Verifica que las reglas existen y la política por defecto no sea hostil en silencio

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

Qué significa: La política por defecto de INPUT es DROP (normal para PVE firewall). Tus permisos explícitos para puertos de gestión existen.

Decisión: Si la política es DROP pero no ves reglas de permitir para tu red fuente, detente y arregla las reglas antes de cerrar tu sesión de trabajo.

Tarea 15: Confirma que el proxy de la GUI es accesible desde tu red cliente

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

Qué significa: El servicio está vivo localmente. Si clientes remotos aún no pueden acceder, es un problema de firewall o de ruta.

Decisión: Prueba desde un host de gestión en la misma subred; si está bloqueado remotamente, inspecciona la coincidencia de IP origen y los caminos bridge/NIC.

Tarea 16: Si debes deshabilitar temporalmente el firewall de PVE, hazlo limpiamente

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

Qué significa: Las reglas del firewall PVE se eliminan y el servicio se detiene (dependiendo de tu entorno, pueden permanecer políticas base).

Decisión: Usa esto solo como una ventana de mantenimiento corta para restaurar la configuración correcta. Luego vuelve a habilitar. “Temporal” tiene tendencia a volverse estilo de vida.

Causas raíz que hacen fallar pve-firewall.service

La mayoría de fallos se agrupan en unos pocos cubos. Conocer el cubo evita que te marees.

1) Errores de sintaxis en archivos de configuración del firewall de PVE

Son los más comunes y los más arreglables. El mensaje de error suele apuntar directamente a un archivo y línea. Causas típicas:

Puerto no numérico en --dport o --sport
Notación CIDR incorrecta
Macro u opción no reconocida
Copiar/pegar reglas de iptables que el parser de PVE no acepta literalmente
Caracteres ocultos por “comillas inteligentes” pegadas desde un sistema de tickets

La señal: los logs dicen “error parsing … line N”. Arregla la línea, reinicia, listo.

2) Conflictos con la gestión de nftables/iptables

El firewall de PVE espera poseer cadenas específicas e insertar hooks de cierta manera. Si otro servicio vacía tablas, cambia políticas por defecto o usa nombres de cadenas en conflicto, puedes obtener una instalación parcial o filtrado inesperado.

A veces nada “falla” a nivel systemd; simplemente pierdes tráfico. Peor aún. El servicio está “activo” y la interrupción pasa a ser un fallo tuyo de manera más sutil.

3) Desajuste kernel/módulos tras actualizaciones

Menos común en nodos PVE estables, pero ocurre cuando:

Actualizaste paquetes del kernel pero no reiniciaste (y cambiaste backends/compat layers de firewall).
Arrancaste en un kernel más antiguo sin piezas netfilter esperadas por tu userspace actual.
Usas un kernel personalizado o módulos mínimos, y las herramientas de firewall de Proxmox suponen valores por defecto.

4) Filtrado en bridges y confusión sobre la ruta de tráfico de gestión

Muchos hosts Proxmox ponen la IP de gestión en un bridge de Linux (vmbr0) para que el host y las VM compartan uplink. Con bridge netfilter habilitado, tu tráfico de gestión del host puede estar sujeto al mismo filtrado que el tráfico de VM. Eso puede estar bien—si lo diseñaste. Si no, es una vía fácil para bloquearte.

Broma corta #2: Si tu IP de gestión vive en un bridge, básicamente pusiste tu propio SSH en una montaña rusa y lo llamaste “diseño de red”.

5) Rarezas en la propagación de configuración del clúster

La configuración del firewall de PVE se guarda bajo /etc/pve, respaldada por el sistema de archivos del clúster (pmxcfs). Si pmxcfs está indispuesto (disco lleno, problemas FUSE, saltos temporales, pérdida de quórum), puedes editar configuraciones que no se aplican correctamente o aplican de forma inconsistente entre nodos.

6) Sorpresas de IPv6

Aun si no “usas IPv6”, tu sistema podría hacerlo. La GUI puede escuchar en IPv6, o los clientes pueden preferir registros AAAA. Si permites solo IPv4 y los clientes llegan por IPv6, parece una falla aleatoria. No lo es. Es confusión determinista.

Errores comunes: síntoma → causa → solución

1) Síntoma: `pve-firewall.service` falla inmediatamente con número de línea

Causa raíz: Error de sintaxis en /etc/pve/firewall/*.fw (config de clúster, nodo o VM).

Solución: Usa journalctl -u pve-firewall -b y nl -ba para localizar la línea. Elimina/repara el token inválido (puertos, CIDR, opciones). Reinicia y confirma activo.

2) Síntoma: Servicio activo, pero GUI/SSH inalcanzable desde un subconjunto de redes

Causa raíz: Permitiste la subred equivocada (a menudo un host bastión NATeado, pool VPN o un nuevo rango WAN corporativo). O permitiste solo IPv4 mientras los clientes llegan por IPv6.

Solución: Confirma las IP origen desde el lado cliente y los logs. Amplía la regla de permitir al grupo de gestión correcto. Añade reglas IPv6 equivalentes si aplica. Verifica con iptables -S/ip6tables -S y una prueba cliente.

3) Síntoma: Reiniciar el firewall intermitentemente corta comunicaciones de clúster

Causa raíz: No se permiten puertos de Corosync (o estás filtrando en la interfaz equivocada). El clustering de Proxmox es parlanchín y sensible a pérdida de paquetes.

Solución: Asegura que la red de clúster y el tráfico nodo-a-nodo estén permitidos en las interfaces correctas. Si separas cluster y gestión, mantén reglas separadas y explícitas. Valida con pvecm status y captura de paquetes si hace falta.

4) Síntoma: El tráfico de VM muere cuando habilitas firewall en host

Causa raíz: Bridge netfilter más política FORWARD DROP sin reglas correctas por bridge/VM. O habilitaste firewall en VMs sin permitir el egress/ingress necesario.

Solución: Decide si quieres firewall a nivel VM. Si sí, crea reglas para forwarding e interfaces tap de VM; prueba una VM primero. Si no, deshabilita filtrado de bridge o firewall de VM y mantén reglas INPUT enfocadas en servicios del host.

5) Síntoma: Inicio de firewall falla después de una actualización; errores mencionan xtables/nft

Causa raíz: Mismatch de backend (legacy vs nf_tables) o selección alternativa en conflicto.

Solución: Revisa iptables --version y el estado de update-alternatives. Elige un backend deliberadamente y asegúrate de que tus herramientas y expectativas coincidan. Reinicia si kernel/userspace están desincronizados.

6) Síntoma: Cambios en GUI no “permanecen”, o nodos muestran comportamiento distinto

Causa raíz: Problemas con pmxcfs / quórum, o editar el ámbito equivocado (datacenter vs nodo vs VM).

Solución: Confirma quórum, revisa pvecm status. Asegúrate de editar el ámbito correcto. Si el quórum es inestable, deja de intentar cirugía de firewall en medio de un ataque cardíaco de clúster.

7) Síntoma: Puedes alcanzar la GUI localmente pero no remotamente, aunque INPUT parezca permitirlo

Causa raíz: Cambios de ruteo/VRF, filtrado de reverse path, o tráfico de gestión llegando por una interfaz distinta a la esperada (bond, subinterfaz VLAN, puerto de bridge).

Solución: Inspecciona rutas y direcciones de interfaz, luego verifica coincidencias de interfaz en reglas. Usa ip route, ip -br a y confirma con captura de paquetes (tcpdump) en la interfaz que crees está en uso.

Tres micro-historias de la vida corporativa

Micro-historia 1: El outage causado por una suposición errónea

En una empresa mediana, un equipo de virtualización “endureció” reglas de firewall de Proxmox para permitir solo GUI (8006) y SSH (22) desde la VLAN de gestión. Eso es razonable, y habría funcionado si la VLAN de gestión fuera desde donde realmente se conectaban los administradores.

La suposición equivocada fue sutil: la mayoría de administradores se conectaban por VPN, y el pool VPN no estaba en la VLAN de gestión. El host bastión que usaban sí estaba en mgmt, pero la nueva política también bloqueó conexiones salientes desde ese bastión a algunas herramientas internas, así que la gente empezó a conectarse directamente desde sus portátiles por VPN. Esas conexiones ahora estaban muertas.

El incidente tuvo un giro especial: las sesiones SSH existentes se mantuvieron (ESTABLISHED), así que parecía que “algunas personas pueden conectarse y otras no”. Eso alimentó discusiones sobre DNS, caches de navegador y si el balanceador estaba “fallando”. No lo estaba. El firewall hizo exactamente lo que se le dijo.

La solución no fue “abrir todo”. Fue tratar al pool de VPN como una fuente de gestión de primera clase, añadirlo explícitamente al grupo mgmt y luego validar desde una ruta cliente real. También añadieron un ítem en la checklist previa al cambio: “Confirmar el rango de IP origen de los humanos”. Aburrido. Efectivo.

Micro-historia 2: La optimización que salpicó

Otra organización decidió que los reinicios del firewall de Proxmox eran “demasiado lentos” durante mantenimiento. Alguien optimizó añadiendo automatización que vaciaba y recargaba reglas directamente con comandos nft en lugar de usar pve-firewall. El tiempo de recarga mejoró. El plano de control empeoró.

Por un tiempo pareció exitoso. Luego una actualización cambió cómo Proxmox generaba nombres de cadenas y las suposiciones del automatismo se rompieron. El script vació tablas diligentemente, recargó un subconjunto incompleto y dejó políticas por defecto en un estado que intermitentemente agujereaba el tráfico según el estado de conntrack.

El efecto contraproducente fue organizacional tanto como técnico: nadie “poseía” el comportamiento resultante. El equipo PVE dijo “no cambiamos nuestra config”, el equipo de red dijo “el firewall es local al host” y el equipo de automatización dijo “el pipeline está verde”. Mientras tanto, el clúster tenía eventos periódicos de fencing porque paquetes de corosync se perdían durante las ventanas de recarga.

Se recuperaron eliminando la astucia. Volvieron a dejar que Proxmox poseyera sus cadenas, y la automatización pasó a validar configs de PVE y llamar pve-firewall restart en ventanas controladas, nodo por nodo. La recarga fue más lenta, pero la plataforma dejó de sorprender a la gente. En producción, la sorpresa es la característica más cara.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Una gran empresa que ejecuta Proxmox para cómputo edge tenía una práctica estándar: cualquier cambio de firewall debía incluir un job de rollback temporizado programado en el propio nodo, además de verificar acceso por consola antes del cambio. Los ingenieros se quejaban porque parecía ceremonia.

Un día, un ingeniero añadió una regla a nivel datacenter para bloquear tráfico entrante a un rango de puertos usado por una app legacy—buena intención, pruebas insuficientes. La regla coincidió accidentalmente con un rango más amplio del previsto. Resultado: SSH quedó bloqueado desde la red del ingeniero y la GUI dejó de cargar.

El ingeniero no entró en pánico. Esperó. Tres minutos después, el rollback detuvo el servicio del firewall, restaurando acceso. Luego se reconectó, corrigió la regla, validó con captura de paquetes y reaplicó con la misma guarda de seguridad. Sin viaje al datacenter, sin ópera de Slack a las 2 a.m.

Ese es el objetivo del proceso aburrido: no está ahí para prevenir errores. Está ahí para hacer los errores sobrellevables.

Listas de verificación / plan paso a paso

Esta es la secuencia que ejecutaría en un nodo real cuando pve-firewall.service falla o cuando un reinicio podría cortar mi propio acceso. Es opinada, porque la ambigüedad es cómo nacen las interrupciones.

Plan paso a paso: reparar sin bloqueo

Consigue acceso por consola si es posible (IPMI/iLO o físico). Si no puedes, abre dos sesiones SSH y no las cierres.
Haz snapshot del estado actual: captura systemctl status, journalctl y la salida de iptables -S/nft list ruleset en un archivo de root para comparación posterior.
Comprueba si el servicio falla al arrancar vs “arranca pero te bloquea”. La vía de solución difiere.
Lee el error exacto desde journalctl -u pve-firewall -b. Si nombra archivo+línea, arregla eso primero. No improvises.
Valida requisitos de alcance de gestión: identifica tus rangos IP reales de origen (pools VPN, bastiones, subredes admin). Actualiza grupos/aliases de firewall acorde.
Programa rollback con at (o ten consola lista). Siempre. Es tu paracaídas.
Reinicia pve-firewall una vez. Si falla otra vez, vuelve a los logs; no spammees reinicios.
Confirma puertos críticos (22/8006) accesibles desde al menos una red admin. Prueba desde un host cliente, no solo localhost.
Confirma salud del clúster tras aplicar: pvecm status y busca inestabilidad de corosync.
Cancela el rollback solo tras confirmación: atrm el job, documenta el cambio y comprométete a limpiar permisos temporales.

Checklist: ítems de seguridad antes del cambio

Acceso por consola verificado (o dos sesiones SSH abiertas).
Rollback programado (at now + 3 minutes).
Snapshot de configuración conocida (copia de /etc/pve/firewall y salida de reglas).
Redes de gestión y pools VPN identificados y presentes como aliases/grupos.
Puertos de clúster y requisitos de red de almacenamiento entendidos (especialmente en diseños multi-NIC).
Cambio aplicado primero a un nodo en el clúster.

Checklist: validación posterior al cambio

systemctl is-active pve-firewall muestra active.
SSH remoto y GUI probados desde redes admin reales.
Conectividad de VM validada si está habilitado firewall en bridge/VM.
No hay nuevos errores de corosync; el clúster mantiene quórum.
Job de rollback cancelado.

Datos interesantes y contexto

Estos no son trivialidades por sí mismas. Explican por qué el firewall de Proxmox se comporta como lo hace y por qué las soluciones a veces parecen contraintuitivas.

Proxmox guarda la config del firewall en el filesystem del clúster (/etc/pve vía pmxcfs). Eso es conveniente—y significa que “problemas de config” también pueden ser “problemas de salud del clúster”.
Linux pasó de iptables a nftables con el tiempo, pero muchas herramientas aún hablan “iptables”. La capa de compatibilidad puede estar bien hasta que alguien asume estabilidad del formato de salida.
Políticas DROP por defecto son normales en el firewall de Proxmox. La expectativa es permitir explícitamente gestión, clúster y servicios. Si estás acostumbrado a “ACCEPT por defecto”, esto se siente agresivo.
Bridge netfilter existe porque la gente quería filtrar tráfico puenteado (VMs en bridges de Linux). También significa que puedes filtrar accidentalmente tu propio tráfico host cuando el host vive en ese bridge.
El estado de conntrack hace que las interrupciones parezcan inconsistentes. Las sesiones establecidas siguen funcionando mientras las nuevas fallan, lo que lleva a equipos a perseguir fantasmas.
Corosync es sensible a pérdida de paquetes y picos de latencia. Una recarga de firewall que bloquee o descarte multicast/unicast brevemente puede parecer inestabilidad de nodo.
La “propiedad” del firewall importa operacionalmente. Si PVE posee las cadenas, déjalo poseerlas. Mezclar orquestadores (PVE + ufw + scripts hechos a mano) es como obtener Heisenbugs.
IPv6 a menudo “funciona por accidente” hasta que deja de hacerlo. Clientes modernos pueden preferirlo y servicios de Proxmox pueden vincularse a él. Si no lo consideras explícitamente, obtendrás reportes de acceso extraños.

Preguntas frecuentes

1) ¿Por qué falló `pve-firewall.service` justo después de editar una regla en la GUI?

Porque la GUI escribe en un archivo .fw bajo /etc/pve/firewall, y el servicio parsea ese archivo. Un único token inválido puede impedir la compilación de reglas y el servicio sale con código no cero. Revisa journalctl -u pve-firewall -b para archivo+línia.

2) ¿Puedo simplemente deshabilitar el firewall y seguir adelante?

Puedes, pero trátalo como una medida de emergencia. Deshabilita para recuperar acceso, arregla la config y vuelve a habilitar. Si deshabilitarse se vuelve permanente, cambias una política controlada por pensamiento deseoso.

3) Reinicié el firewall y ahora SSH murió. ¿Cuál es la recuperación más rápida?

Usa consola fuera de banda y detén el servicio: systemctl stop pve-firewall o pve-firewall stop. Luego arregla reglas de permitir para tus redes admin antes de iniciarlo de nuevo. Si tenías un job de rollback programado, espera a que se dispare.

4) ¿El firewall de Proxmox usa nftables o iptables?

Usa la pila netfilter y las herramientas del sistema. En sistemas modernos basados en Debian a menudo verás iptables (nf_tables). El punto práctico: no asumas comportamiento legacy de iptables o formato de salida en scripts.

5) ¿Por qué sobreviven sesiones SSH existentes cuando las nuevas fallan?

Por connection tracking. Muchas políticas permiten ESTABLISHED,RELATED. Tu sesión ya abierta coincide con eso, mientras que las nuevas conexiones no. Por eso “a mí me funciona” no es evidencia.

6) ¿Cómo sé qué ámbito de firewall me está rompiendo (Datacenter vs Nodo vs VM)?

Empieza con los logs para fallos de parsing (nominan el archivo). Para problemas de comportamiento, deshabilita temporalmente un ámbito a la vez (preferiblemente vía consola) y observa. Las reglas de datacenter son las más amplias; las de nodo aplican al host; las de VM afectan tráfico invitado (y a veces forwarding según la configuración).

7) ¿Necesito permitir puertos de corosync en el firewall?

Si tienes PVE firewall aplicando INPUT/FORWARD, sí—al menos en las interfaces usadas para comunicación de clúster. Si aislas el tráfico de clúster en una red dedicada, mantén las reglas de permitir restringidas a esa red, no al mundo entero.

8) ¿Y si sospecho que pmxcfs/quórum están causando rarezas en la config del firewall?

Revisa pvecm status para quórum y confirma que puedes leer/escribir bajo /etc/pve. Si se pierde quórum, prioriza restaurar la salud del clúster. Editar config de firewall en un clúster degradado es una buena manera de producir resultados inconsistentes.

9) ¿Es seguro vaciar reglas iptables/nft manualmente?

Puedes, pero es una herramienta afilada. Si vacías tablas sin entender qué más depende de ellas (NAT para VMs, restricciones de tráfico de almacenamiento, reglas de clúster), puedes crear nuevas interrupciones. Prefiere arreglar la config de PVE y dejar que la aplique limpiamente.

10) ¿Debería poner la IP de gestión de Proxmox en un bridge?

Es común y puede estar bien. Pero una vez que la gestión vive en un bridge, bridge netfilter y políticas de forwarding forman parte de tu historia de acceso al host. Si quieres modos de fallo más simples, una NIC/VLAN de gestión dedicada no ligada al forwarding de VM es más tranquila.

Conclusión: próximos pasos que no dañan

La solución segura para pve-firewall.service failed rara vez es “intentar otra vez”. Es: lee el log, arregla el error de configuración exacto y reinicia una vez—bajo una guarda de rollback—mientras confirmas que permites las redes que las personas usan realmente.

Próximos pasos prácticos:

Extrae journalctl -u pve-firewall -b y resuelve cualquier error de parsing archivo/línea.
Define un grupo de gestión apropiado (incluyendo pools VPN y bastiones) y permite explícitamente 22/8006 desde él.
Adopta el hábito de “rollback temporizado” para cambios en el firewall. Parece paranoia hasta que te ahorra una hora.
Si administras clústeres, prueba cambios de firewall en un nodo primero y verifica quórum del clúster después de aplicar.