Firewall de Proxmox te bloqueó: restaurar SSH/Web UI desde la consola sin pánico

noviembre 4, 2025 • febrero 3, 2026 • Lectura: 28 min • Views: 7

¿Te fue útil?

Modificaste una regla de firewall en Proxmox. Ahora la interfaz web se queda colgada, SSH no responde y tienes la sensación de que el estómago va a salir por la garganta. No estás “caído”. Estás simplemente inaccesible de forma remota—como una pieza de museo.

Esta es una guía de recuperación centrada en la consola para cuando la política de firewall de Proxmox bloquea tu propio acceso de gestión. Está escrita para quienes administran sistemas en producción: quieres la ruta más rápida y segura para volver a tener SSH y el puerto 8006, y además comprender qué falló para que no vuelva a ocurrir.

Guía rápida de diagnóstico

Si estás bloqueado, tu trabajo no es “depurar todo”. Tu trabajo es restaurar una vía de gestión que funcione, y después mejorar con seguridad. Aquí tienes la ruta más rápida que evita empeorar las cosas.

Primero: determina si es firewall, servicio o red

¿Puedes acceder a la máquina por consola? Si sí, sigue. Si no, tu problema está aguas arriba (consola del hipervisor, IPMI/iLO/DRAC, acceso físico).
¿La red del host está operativa? Comprueba el estado del enlace, la dirección IP y la ruta por defecto. Si la red está rota, el firewall no es el problema principal.
¿Está corriendo el stack de gestión de Proxmox? Comprueba pveproxy (Web UI) y sshd (SSH). Si los servicios están abajo, arregla los servicios primero.

Segundo: confirma que el firewall está realmente activo

Comprueba si el firewall de Proxmox está habilitado a nivel de datacenter/nodo.
Revisa si pve-firewall está en ejecución y si instaló reglas en nftables/iptables.

Tercero: ejecuta la recuperación de menor riesgo

Deshabilita temporalmente el servicio de firewall de Proxmox (systemctl stop pve-firewall) para restaurar el acceso, o
Inyecta una regla de permitir estrecha para SSH y 8006 desde tu(s) IP(s) de administración, luego recarga el firewall.

Cuarto: verifica externamente y arregla la política correctamente

Verifica SSH y la interfaz web desde una máquina administrativa conocida.
Revisa el conjunto de reglas que causó el bloqueo (datacenter vs nodo vs VM, input vs output, alcance por interfaz).
Implementa una estrategia permanente de “lista blanca de gestión”, no un montón de excepciones improvisadas.

Verdad directa: si no sabes qué regla está mal, deja de adivinar. Desactiva el firewall, restaura el acceso y corrige las reglas a la luz del día.

Cómo funciona realmente el firewall de Proxmox (las partes que importan en una caída)

Proxmox VE tiene una función de firewall integrada en la interfaz, con capas y ámbitos:

Datacenter reglas: globales en todos los nodos (intención a nivel de clúster).
Nodo reglas: específicas del host, a menudo para acceso de gestión/plano de control.
VM/CT reglas: aplicadas a los invitados (útiles, pero no para esta emergencia).

Por debajo, Proxmox programa el firewall del host a través de su servicio pve-firewall. Dependiendo de la distro/kernel, las reglas van a nftables o a una capa de compatibilidad de iptables. Durante un bloqueo te interesan dos cosas:

Políticas por defecto: la política de entrada puede volverse “drop a menos que esté permitido” cuando el firewall está habilitado con una postura deny por defecto.
Puertos de gestión: SSH (típicamente 22) y la interfaz web de Proxmox (8006/TCP vía pveproxy).

El firewall de Proxmox no es magia, pero puede sentirse así cuando te bloquea y estás frente a la consola. Tu recuperación depende de entender que:

Parar pve-firewall normalmente elimina las reglas que gestiona (ese es el “botón rojo grande”).
Reiniciar pveproxy no ayuda si el firewall descarta el tráfico antes de que llegue al servicio.
Las reglas de clúster pueden propagarse y arruinarte el día en varios nodos si usaste el ámbito datacenter sin cuidado.

Una idea de confiabilidad parafraseada de John Allspaw: Los incidentes suelen ser el resultado de trabajo normal y decisiones locales que tenían sentido en su momento. Trata tu bloqueo como un incidente. Lo arreglarás más rápido y aprenderás más.

Hechos interesantes y contexto histórico (para que tu cerebro deje de adivinar)

El puerto 8006 es el puerto por defecto de la interfaz web de Proxmox; no es “especial”, pero es fácil bloquearlo con una sola regla mala.
Proxmox VE se basa en Debian, lo que significa que tu kit de rescate es el Linux clásico: systemd, journalctl, iproute2 y nftables/iptables.
El firewall en Linux ha evolucionado: iptables dominó durante años; nftables es el reemplazo moderno, pero las capas de compatibilidad pueden confundir la salida en emergencias.
Firewalls stateful (conntrack) implican que reglas “allow established/related” pueden salvar sesiones existentes mientras bloquean nuevas—por eso tu SSH actual puede sobrevivir mientras otros no entran.
Políticas por defecto DROP son más seguras que ALLOW por defecto, pero solo si prepermites la gestión. La seguridad ama “denegar por defecto”. Operaciones ama “no dejar el host inservible”. Puedes tener ambas cosas.
La propagación de configuración del clúster multiplica efectos: hace los cambios consistentes y los errores consistentes también.
La disponibilidad de la interfaz web depende de pveproxy y TLS; un bloqueo de firewall se ve idéntico a un proxy muerto desde el navegador.
Consolas fuera de banda (IPMI/iLO/DRAC) existen porque las redes fallan y los humanos las reconfiguran mal; “acceso por consola” no es una característica de lujo.
Las abstracciones de UI del firewall ayudan hasta que ocultan el orden real de las reglas y el emparejamiento por interfaz—entonces aprendes por las malas que “simple” aún tiene casos límite.

Accede a una consola real (no, no a tu pestaña SSH medio funcional)

Cuando Proxmox te bloquea, necesitas acceso local. Opciones, en orden de sensatez:

Consola IPMI/iLO/DRAC/KVM: la mejor para recuperación remota. Úsala.
Consola física: carrito de rescate, monitor y teclado. A la vieja usanza, funciona.
Consola del proveedor: si está alojado con un tercero, usa su “VNC/serial console”. Acepta la rareza.

Una vez dentro, evita las sacudidas. No empieces a editar archivos de configuración al azar. Tómate 90 segundos para confirmar: red, servicios, firewall. Luego actúa.

Chiste #1: El firewall no “se rompió”. Simplemente desarrolló un fuerte sentido de límites personales.

Tareas de recuperación desde la consola (comandos, salidas y decisiones)

A continuación hay tareas prácticas que puedes ejecutar desde la consola. Cada una incluye: el comando, qué significa la salida y la decisión que debes tomar. No las ejecutes a ciegas; sigue la lógica de decisión.

Task 1: Confirma que estás en el nodo correcto y no estás soñando

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

Qué significa: Estás en el nodo que crees y ejecuta un kernel de Proxmox.

Decisión: Si este no es el nodo correcto, para y encuentra el adecuado. Si lo es, continúa.

Task 2: Comprueba el enlace y la dirección IP (verificación básica de red)

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

Qué significa: El bridge está arriba y tiene la IP de gestión.

Decisión: Si la interfaz está DOWN o falta la IP, arregla la red primero (VLAN equivocada, cable, bond, configuración del bridge). Los cambios de firewall no arreglarán un host sin IP.

Task 3: Confirma la ruta por defecto y que puedes alcanzar tu gateway

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

Qué significa: Existe conectividad L2/L3 básica. Probablemente puedas recuperar la gestión sin reenfilar nada físico.

Decisión: Si el ping al gateway falla, busca problemas en trunks VLAN, puertos del bridge, estado del bond o configuración del switch upstream. Otra vez: no culpes al firewall todavía.

Task 4: Comprueba si los servicios SSH y Web UI están en ejecución

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

Qué significa: Los servicios están activos. Si aún no puedes acceder de forma remota, el firewall es muy sospechoso.

Decisión: Si alguno está inactivo o fallado, arréglalo primero. Un cambio en el firewall no revivirá un daemon muerto.

Task 5: Verifica que los servicios escuchan en los puertos esperados localmente

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

Qué significa: El host acepta conexiones en 22 y 8006. Si los clientes remotos no pueden conectar, los paquetes están siendo filtrados o mal enrutados.

Decisión: Si los puertos no están escuchando, revisa la configuración del servicio, problemas de certificados o bucles de fallo en los logs.

Task 6: Prueba que el firewall es el bloqueador con 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

Qué significa: La interfaz web funciona localmente. El síntoma “caído” es camino de red o firewall, no pveproxy en sí.

Decisión: Pasa a inspeccionar y revertir el firewall.

Task 7: Comprueba si el firewall de Proxmox está habilitado en tiempo de ejecución (servicio + estado)

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

Qué significa: El firewall de Proxmox está activo y gestiona reglas.

Decisión: Si estás bloqueado y necesitas una restauración rápida, detener este servicio es un movimiento de emergencia legítimo. Si necesitas una restauración parcial (lista blanca estricta), edita reglas en su lugar.

Task 8: Revisa los logs del firewall para ver descartes (esto evita adivinar)

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

Qué significa: Los logs del kernel muestran que tu host administrativo (10.20.30.50) está siendo descartado en los puertos 8006 y 22. Es una evidencia contundente, no una interpretación.

Decisión: Aplica un allow de emergencia (preferible si puedes ser preciso) o detén pve-firewall (más rápido).

Task 9 (más rápido): Para el firewall de Proxmox para restaurar el acceso inmediatamente

cr0x@server:~$ systemctl stop pve-firewall

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

Qué significa: El conjunto de reglas gestionadas por Proxmox debería retirarse. El acceso remoto debería volver si el firewall era el bloqueador.

Decisión: Intenta SSH/Web UI desde tu máquina administrativa ahora. Si el acceso regresa, confirmaste la causa raíz. Luego: arregla las reglas correctamente y vuelve a habilitar el firewall.

Task 10: Si el acceso sigue sin volver, inspecciona nftables/iptables directamente

A veces otras herramientas, scripts personalizados o reglas residuales permanecen. Comprueba lo que realmente está cargado.

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

Qué significa: Un ruleset mínimo de nftables con política de entrada accept. Si esto es lo que ves, probablemente no haya filtrado a nivel de nft.

Decisión: Si ves policy drop y no hay reglas que permitan tus puertos de gestión, puedes añadir una regla temporal de permitir (ver tarea siguiente). Si nft está vacío pero sospechas de iptables, revisa iptables también.

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

Qué significa: iptables es permisivo. Si aún estás bloqueado, sospecha de enrutamiento, rp_filter, ACL upstream o IP equivocada.

Decisión: Continúa con pruebas de conectividad y revisiones upstream.

Task 11 (quirúrgico): Permite temporalmente SSH y 8006 desde tu IP administrativa usando nftables

Si necesitas mantener una postura default-drop mientras recuperas, añade un allow estrecho para tu workstation o bastión. Esto asume que nftables está activo en tu nodo.

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

Qué significa: Creaste una cadena “emergencia” de alta prioridad que acepta el tráfico de gestión desde una IP antes de que otras cadenas puedan descartarlo.

Decisión: Usa esto para volver a entrar remotamente, luego corrige las reglas del firewall de Proxmox correctamente. Elimina la tabla emergency después; no dejes cinta de escena del crimen en producción.

Task 12: Revisa los archivos de configuración del firewall de Proxmox (encuentra la regla que te dañó)

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

Qué significa: La política de entrada a nivel de clúster es DROP y hay un DROP explícito para 8006. Así es como dejaste inservible la UI—a escala y con educación.

Decisión: Elimina la regla DROP mala, añade una regla de lista blanca para tu subred administrativa y mantén policy_in DROP si esa es tu postura de seguridad. Solo no niegues tu propio plano de control.

Task 13: Añade una regla de permitir correcta en el firewall de Proxmox (solución permanente preferida)

Ejemplo: permitir gestión desde una subred administrativa al nodo.

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

Qué significa: El nodo tiene allows explícitos para SSH y Web UI desde tu subred administrativa, mientras sigue descartando por defecto todo lo demás entrante.

Decisión: Si tu subred administrativa no es de confianza, reemplázala por la IP del bastión o el rango VPN. “0.0.0.0/0 puede gestionar mi hypervisor” no es una estrategia de seguridad.

Task 14: Recarga el firewall de Proxmox y verifica que compila

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

Qué significa: El servicio está activo; las reglas compilan sin errores.

Decisión: Si la compilación falla, el firewall puede revertir o aplicarse parcialmente. Corrige la sintaxis antes de confiar en él. Un firewall “aplicado a medias” es como un fantasma que te persigue.

Task 15: Valida desde el host: ¿siguen descartándose paquetes?

No puedes simular perfectamente el acceso remoto desde la consola local, pero puedes comprobar si el kernel sigue registrando descartes para tu origen administrativo.

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

Qué significa: Si no hay nuevos descartes mientras intentas conectar remotamente, probablemente lo solucionaste. Si los descartes persisten, tu regla de permitir no está coincidiendo (rango origen equivocado, interfaz, protocolo o ámbito).

Decisión: Si los descartes persisten, revisa el orden de reglas y el ámbito (datacenter vs nodo). También verifica si estás llegando desde una IP distinta a la que crees (NAT, VPN, jump host).

Task 16: Confirma la ruta remota con tcpdump (cuando necesitas pruebas, no sensaciones)

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

Qué significa: Ves SYN y SYN-ACK. Eso es conectividad. Si el SYN llega pero no hay SYN-ACK, el host está descartando o no está escuchando.

Decisión: SYN solo usualmente significa drop de firewall. SYN+SYN-ACK significa que volviste; cualquier problema restante probablemente sea TLS/certificados/navegador o un proxy inverso delante.

Task 17: Comprueba si te bloqueaste por interfaz (vmbr0 vs subinterfaz 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

Qué significa: El filtrado VLAN está habilitado en el bridge. Si tu etiquetado de VLAN o suposición de PVID para gestión es incorrecta, el tráfico puede ni siquiera alcanzar el host como crees.

Decisión: Si recientemente cambiaste VLANs/configuración del bridge junto con el firewall, aísla: confirma L2/VLAN primero y luego el firewall.

Task 18: Verifica la salud del filesystem del clúster (porque /etc/pve es especial)

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

Qué significa: Si estás en un clúster, /etc/pve es un filesystem de clúster. Problemas de quorum pueden hacer que las ediciones de configuración sean complicadas o no se propaguen.

Decisión: Si no hay quorum, evita hacer suposiciones “globales”. Prefiere la restauración de acceso local por nodo y procede con cuidado.

Chiste #2: Nada enseña “control de cambios” como presentarte físicamente en la sala de servidores a las 2 a.m.

Tres microhistorias corporativas (dolor, arrepentimiento y un héroe silencioso)

Microhistoria 1: El incidente causado por una suposición equivocada

Una empresa mediana usaba Proxmox para cargas internas: runners de CI, algunas bases de datos y un clúster de VMs “temporales” que de alguna manera vivieron años. Un nuevo líder de seguridad pidió “deny por defecto inbound” en los hipervisores. Razonable. El equipo estuvo de acuerdo—y luego hicieron la parte peligrosa: asumieron que su subred de VPN era la única fuente de tráfico de gestión.

En realidad, el equipo de operaciones usaba un bastión en otra subred para mantenimiento. El bastión se configuró durante una reorganización de red y se convirtió en la vía administrativa de facto. El cambio de firewall permitió SSH y 8006 desde la VPN y bloqueó todo lo demás.

Al principio, nada parecía roto. Las sesiones SSH ya abiertas siguieron funcionando porque las reglas stateful permitieron conexiones establecidas. Eso hizo que el cambio pareciera seguro. Luego el bastión se reinició para actualizaciones del kernel. Cuando volvió, no pudo SSH a los nodos. La UI web también dejó de funcionar. De repente el despliegue “deny por defecto” parecía una caída.

La solución fue simple: consola a un nodo, parar pve-firewall, añadir un allow para la subred del bastión, arrancar pve-firewall, probar desde bastión y VPN. La lección no fue “no hagas deny por defecto”. La lección fue que las suposiciones sobre las rutas de gestión son mentiras a menos que las inventaries.

Después del incidente escribieron un “contrato del plano de gestión” de una página: qué subredes pueden acceder a los hipervisores, qué puertos y cómo probar desde cada vía antes de habilitar DROP. Fue aburrido. Funcionó.

Microhistoria 2: La optimización que rebotó

Otra organización tenía la costumbre de “optimizar” reglas para mantenerlas ordenadas. Un ingeniero decidió consolidarlas en el ámbito datacenter para que todos los nodos se comportaran igual. Argumento: menos excepciones por nodo, menos “copos de nieve”, más cumplimiento. En principio, bien.

El fallo vino por heterogeneidad. Algunos nodos tenían gestión en vmbr0 sin VLAN; otros usaban una VLAN etiquetada en vmbr0.20. Las reglas consolidadas incluían coincidencias por interfaz que eran correctas para la mitad del parque y erróneas para la otra mitad. Los nodos afectados no coincidían con las reglas allow, así que se aplicó el DROP por defecto.

Perdieron acceso a múltiples nodos a la vez, el tipo de caída que hace que los ejecutivos pregunten “¿Por qué no podemos simplemente entrar?”. El equipo tuvo que usar consolas fuera de banda para recuperarlos, uno a uno, mientras el resto de la empresa miraba una página de estado con lenguaje prudente.

Lo que lo empeoró: como las reglas eran a nivel de clúster, “arreglarlo rápido” implicaba empujar otro cambio global, y el equipo dudó por miedo a repetir el problema. Terminaron parando pve-firewall en los nodos bloqueados, restaurando acceso y rediseñando reglas en torno a grupos de gestión: una lista blanca por redes origen y puertos sin suposiciones frágiles por interfaz.

El punto: consolidar no es automáticamente simplificar. Si el entorno no es uniforme, una “optimización global” es a veces solo un radio de impacto global.

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

Una entidad de servicios financieros gestionaba un clúster Proxmox para entornos de prueba—todavía importante y con plazos reales. Tenían una regla estricta: cualquier cambio de firewall debía incluir una vía “romper el vidrio” preconfigurada, probada desde otra red.

Esa vía era deliberadamente aburrida: un jump host administrativo con IP fija, permitido para SSH y 8006 en todos los hipervisores, y monitorizado. También tenían IPMI habilitado y documentado, con credenciales en una bóveda controlada. A nadie le gustaba mantenerlo. No era un trabajo glamuroso.

Una tarde, alguien aplicó por accidente una regla datacenter que descartaba todo el TCP entrante salvo unos puertos de aplicación. Fue un error honesto de UI: el ingeniero pensó que editaba la política de una VM, no la del datacenter. En segundos la mayor parte del acceso de gestión desapareció.

El equipo no entró en pánico. Usaron el jump host, que seguía teniendo acceso por diseño, para conectarse a los nodos y revertir la regla. No hubo acrobacias con la consola. No hubo adivinanzas. El postmortem fue corto y sin romance: mejorar guardrails de UI, añadir prompts de confirmación para cambios en datacenter y mantener el jump host monitorizado.

A veces la mejor decisión de ingeniería es ser deliberadamente poco interesante.

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

Esta sección es donde emparejas lo que ves con lo que realmente está ocurriendo. El reconocimiento rápido de patrones vence al sufrimiento creativo.

1) El navegador se agota en el puerto 8006, pero curl en consola funciona

Síntoma: Interfaz web inaccesible remotamente, pero curl -kI https://127.0.0.1:8006/ devuelve 200.
Causa raíz: Firewall descartando TCP/8006 entrante o ACL upstream bloqueando.
Solución: Para pve-firewall para restaurar acceso, luego añade reglas explícitas que permitan TCP/8006 desde orígenes administrativos y recarga.

2) SSH funcionaba para una persona, luego dejó de hacerlo al desconectarse

Síntoma: Una sesión SSH existente sobrevivió; nuevas sesiones fallan.
Causa raíz: Allow stateful para conexiones establecidas, pero TCP/22 entrante nuevo se descarta.
Solución: Añade un allow explícito para TCP/22 desde orígenes administrativos; no confíes en la suerte de conntrack.

3) Solo un nodo está bloqueado; los demás funcionan

Síntoma: El clúster es mayoritariamente accesible; un nodo inaccesible por SSH/UI.
Causa raíz: Firewall a nivel de nodo habilitado con política más estricta, mismatch de interfaz o error tipográfico en la regla del nodo.
Solución: Revisa /etc/pve/firewall/pve-XX.fw para enable y políticas; compáralo con un nodo funcional; reinicia pve-firewall tras corregir.

4) Todo quedó inaccesible justo después de editar el firewall del datacenter

Síntoma: Varios nodos se vuelven inalcanzables casi simultáneamente.
Causa raíz: Regla a nivel de clúster (datacenter) que descartó puertos de gestión o cambio de política a DROP sin lista blanca.
Solución: Conéctate por consola a un nodo, para pve-firewall, edita /etc/pve/firewall/cluster.fw para permitir gestión, arranca firewall, valida y repite según necesites.

5) La interfaz web funciona en LAN pero no por VPN

Síntoma: La subred local llega a 8006; usuarios por VPN no.
Causa raíz: Reglas allow limitadas a una subred; NAT de VPN cambia la IP origen; o problemas de MTU que aparentan ser firewall.
Solución: Confirma la IP de origen del VPN vista por Proxmox vía logs del firewall o tcpdump; ajusta la regla allow en consecuencia; si ves SYN-ACK pero la UI falla, comprueba MTU/TLS en vez de firewall.

6) Parar pve-firewall no restaura el acceso

Síntoma: systemctl stop pve-firewall pero SSH/UI siguen inaccesibles.
Causa raíz: Reglas aplicadas por nftables/iptables que no pertenecen a pve-firewall, firewall/ACL upstream, ruta equivocada o IP incorrecta.
Solución: Inspecciona nft list ruleset y iptables -S, verifica IP/ruta, ejecuta tcpdump para ver si el SYN llega al host y revisa la política de red upstream.

7) Permitiste 8006 pero aún no puedes iniciar sesión

Síntoma: TCP conecta pero la autenticación en la UI falla o carga parcialmente.
Causa raíz: No es firewall: puede ser pveproxy, desincronización horaria, problema en el backend de autenticación o desajuste de certificado/hostname (especialmente detrás de proxies).
Solución: Revisa systemctl status pveproxy, examina journalctl -u pveproxy, confirma sincronización de tiempo y prueba el inicio de sesión local primero.

8) Editaste /etc/pve/firewall pero nada cambia

Síntoma: Los cambios no se aplican, las reglas parecen iguales.
Causa raíz: Filesystem de clúster no saludable (problemas de quorum), o editaste el archivo del ámbito equivocado.
Solución: Comprueba pvecm status por quorum; asegúrate de haber editado el archivo correcto (cluster.fw vs *.fw del nodo); reinicia pve-firewall y confirma el estado de compilación.

Listas de verificación / plan paso a paso

Emergencia paso a paso (restaurar acceso en menos de 10 minutos)

Abrir acceso por consola (IPMI/KVM/consola del proveedor).
Confirmar IP y ruta:
- ip -br addr muestra la IP de gestión correcta.
- ip route muestra la ruta por defecto.
Confirmar servicios:
- systemctl status ssh y systemctl status pveproxy.
- ss -lntp | egrep '(:22|:8006)'.
Confirmar descartes del firewall (opcional pero rápido):
- journalctl -k | egrep -i 'PVEFW|DROP|REJECT'.
Elegir modo de recuperación:
- Más rápido: systemctl stop pve-firewall.
- Más controlado: añade un allow estrecho para tu IP administrativa (cadena nft emergency temporal) o edita /etc/pve/firewall/*.fw.
Verificar desde fuera: prueba SSH y https://node:8006 desde un host administrativo conocido.
Arreglar la regla real: elimina deny, añade lista blanca correcta, recarga firewall (systemctl start pve-firewall y pve-firewall compile).
Eliminar reglas nft temporales si las creaste:
- nft delete table inet emergency

Lista de estabilización (tras volver a entrar)

Identificar el ámbito: ¿fue Datacenter, Nodo o VM/CT?
Confirmar políticas: policy_in y policy_out en cada ámbito.
Definir orígenes de gestión: subred VPN, IP del jump host, laptops on-call, NAT de oficinas—escríbelo.
Implementar una lista blanca de gestión:
- Permitir TCP/22 y TCP/8006 desde esa lista.
- Permitir ICMP desde esa lista (opcional, pero útil operacionalmente).
Probar desde cada vía: VPN, jump host, red de oficina, etc. No asumas.
Habilitar logging de descartes solo donde sea necesario; demasiado ruido lo oculta todo.
Documentar el break-glass: dónde está la consola, cómo acceder y quién puede hacerlo.

Prevención: hacer que los bloqueos sean aburridos

Una vez recuperes el acceso, haz lo responsable: evita recurrencias. No con esperanza. Con diseño.

1) Separa “plano de gestión” de “todo lo demás”

Si la gestión del hipervisor comparte la misma LAN y políticas que el tráfico de invitados, te estás invitando al desastre. Patrones mejores:

VLAN/subred de gestión dedicada con ingress controlado.
VPN administrativa que te sitúe en esa subred (o que haga NAT a una IP de salida conocida).
Bastion host con IP estable y autenticación fuerte. Permite la gestión solo desde él si puedes.

2) Mantén tu “lista blanca para SSH y 8006” explícita y local

Puedes establecer policy_in DROP globalmente, pero no confíes en una regla frágil a nivel de datacenter para preservar tu único acceso. Usa reglas de nodo para listas blancas de gestión, especialmente si los nodos difieren (interfaces, etiquetas VLAN, subredes).

3) Usa “regla de dos personas” para cambios en el firewall de datacenter

El ámbito datacenter es un radio de impacto del clúster. Trátalo como cambios de esquema en bases de datos productivas: revisa, verifica el alcance y ten rollback.

4) Prueba con una conexión nueva, no con tu sesión afortunada

Los firewalls stateful pueden engañarte. Siempre valida con una nueva conexión SSH desde un segundo terminal, o desde otro host, antes de declarar éxito.

5) Prefiere cambios temporales y estrechos durante incidentes

En una caída, “parar pve-firewall temporalmente” es aceptable porque es reversible y rápido. Pero no dejes el firewall apagado por días. Lo temporal se vuelve permanente, y lo permanente se convierte en política.

6) Crea un flujo de trabajo “break-glass” que puedas ejecutar medio dormido

Como mínimo:

Acceso fuera de banda verificado trimestralmente.
Un procedimiento documentado para login por consola.
Una IP/rango administrativo conocido para permitir.
Un snippet pre-escrito para reglas de nodo que permitan TCP/22 y TCP/8006.

Preguntas frecuentes

1) ¿Debería desactivar el firewall de Proxmox permanentemente?

No. Desactívalo brevemente para recuperar acceso y luego corrige la política. Los hipervisores son sistemas con privilegios; tenerlos abiertos es una invitación a auditorías dolorosas.

2) ¿Cuál es el comando más rápido y seguro para restaurar el acceso?

Desde la consola: systemctl stop pve-firewall. Si los servicios están corriendo y la red está bien, eso suele restaurar SSH y la interfaz web de inmediato.

3) ¿Por qué la interfaz web usa el puerto 8006, y puedo cambiarlo?

8006 es el puerto por defecto de pveproxy. Puedes cambiar la exposición con proxies inversos y policy de red, pero cambiar el puerto en sí rara vez compensa la fricción operativa durante incidentes.

4) Paré pve-firewall pero sigo bloqueado. ¿Y ahora qué?

Demuestra si los paquetes llegan al host. Usa tcpdump -ni vmbr0 tcp port 22 mientras intentas conectar. Si no llega SYN, es upstream (ruta, VLAN, ACL). Si llega SYN pero no hay SYN-ACK, es filtrado local o problema de servicio/escucha.

5) ¿Es mejor arreglar reglas vía UI o editando /etc/pve/firewall/*.fw?

En una emergencia, edita lo que sea más rápido y menos propenso a errores para ti. La UI es más agradable pero puede no estar disponible durante el bloqueo. Editar por consola está bien; solo valida con pve-firewall compile y reinicia el servicio.

6) ¿Qué regla siempre debería existir para evitar quedar fuera?

Un allow explícito para TCP/22 y TCP/8006 desde una fuente de gestión controlada (IP del bastión o subred administrativa), a nivel de nodo si tu entorno es heterogéneo.

7) ¿Pueden las reglas de VM/CT bloquearme el acceso al host?

No directamente. Las reglas de VM/CT se aplican a interfaces de invitados. Los bloqueos del host suelen venir de ajustes de firewall a nivel de datacenter/nodo u otras herramientas de firewall a nivel de host.

8) ¿Cómo sé si Proxmox usa nftables o iptables?

Comprueba qué tiene reglas cargadas: nft list ruleset y iptables -S. En sistemas Debian modernos nftables es común, a veces con compatibilidad de iptables. Durante una caída, confía en lo que está presente ahora, no en lo que recuerdas del año pasado.

9) ¿El IPv6 puede causar “bloqueos parciales”?

Sí. Si los clientes prefieren IPv6 y tus reglas solo permiten IPv4 (o viceversa), verás acceso inconsistente. Revisa ip -br addr por direcciones IPv6 y asegúrate de que la política coincida con la realidad.

10) Si estoy en un clúster, ¿puedo arreglar esto desde cualquier nodo?

Depende. Si el bloqueo afecta a todos los nodos, necesitarás consola en al menos uno. Además, si el clúster no tiene quorum, /etc/pve puede comportarse de forma limitada. En emergencias, restaura acceso por nodo primero y reconcilia la configuración del clúster cuando esté estable.

Conclusión: próximos pasos que deberías hacer hoy

Quedar fuera por reglas de firewall de Proxmox es común porque la UI es limpia sobre una herramienta afilada. La recuperación es directa: confirma red, confirma servicios, confirma descartes del firewall y luego para pve-firewall o añade un allow estrecho para recuperar acceso. Después, corrige las reglas con listas blancas de gestión explícitas y el ámbito correcto.

Próximos pasos que pagan la renta:

Crea una lista blanca de gestión a nivel de nodo para TCP/22 y TCP/8006 desde un bastión o subred administrativa.
Verifica que el acceso fuera de banda funcione antes de que el siguiente incidente te obligue a descubrir que no funciona.
Añade una prueba simple previa al cambio: “¿Puede una nueva conexión SSH y una nueva conexión 8006 desde cada vía administrativa?”
Mantén tu plan de rollback como un comando que puedas escribir desde la consola sin pensar: parar firewall, restaurar acceso y luego corregir la política.