Estás administrando un nodo Proxmox de forma remota. La Web UI responde en TCP 8006, SSH en TCP 22, y la activación del firewall plantea inmediatamente la pregunta correcta: ¿por qué fuente de administración podrás ingresar si falta una regla?
El procedimiento se mantiene intencionadamente limitado: consola IPMI, KVM o local, recopilación de lo existente, perímetro management, permisos 8006 y 22, compilación, simulación, y luego activación de un solo nivel. Pruebas desde una nueva conexión antes de seguir adelante.
El firewall de Proxmox actúa en varios niveles
Proxmox distingue los niveles Datacenter, Node y VM/CT. El archivo /etc/pve/firewall/cluster.fw contiene la configuración compartida del clúster. El archivo /etc/pve/nodes/<nodename>/host.fw se refiere a un nodo específico. Las reglas de VM y de contenedor viven en /etc/pve/firewall/<VMID>.fw.
Las reglas del nodo pueden provenir del Datacenter o del archivo del host. El nivel del host tiene prioridad sobre el nivel del Datacenter. Para esta primera activación, protege primero el acceso al nodo y no mezclas Datacenter, Node y VM/CT en el mismo cambio.
La documentación de Proxmox indica que el firewall está desactivado por defecto a nivel de clúster con enable: 0. Una vez activado, el tráfico hacia los hosts está bloqueado por defecto, salvo excepciones documentadas como el tráfico local, las conexiones establecidas y algunos flujos internos. Por lo tanto, un acceso remoto a 8006 o 22 debe basarse en una fuente de administración identificada.
Preparar la consola y recopilar lo existente
Antes de cualquier política restrictiva, abre una consola independiente: IPMI, KVM, acceso local o consola provista por el proveedor. Una sesión SSH abierta ayuda a observar el cambio, pero no constituye un verdadero rescate si pasa por la misma red que tu acceso habitual.
Desde el nodo, recopila el nombre, las direcciones, la ruta y el estado actual del firewall:
hostname
ip -br address
ip route
pve-firewall statusToma nota de la dirección IP realmente utilizada por tu equipo, tu VPN o tu bastión de administración. No te limites a la IP del nodo: la regla debe reconocer la fuente de la conexión entrante.
Si el camino de administración aún pasa por un puente Proxmox a modificar, trata esta modificación por separado con la guía sobre la configuración de un puente de red Proxmox. El firewall no debe utilizarse para corregir al mismo tiempo un cambio de interfaz o de puerta de enlace.
Definir las fuentes de administración
El IPSet estándar management se aplica a los firewalls de los hosts. Puede agrupar la IP pública de administración o el subred del VPN utilizado para la Web UI, VNC, SPICE y SSH. La red del clúster local se añade automáticamente a través del alias cluster_network para la comunicación entre hosts.
Un ejemplo de documento en /etc/pve/firewall/cluster.fw se parece a esto:
[IPSET management]
203.0.113.10
192.0.2.0/24203.0.113.10 y 192.0.2.0/24 son valores de ejemplo. Reemplázalos por tu fuente real, y luego verifica la dirección desde la cual abres la nueva sesión. Una IP pública que cambia, un VPN que sale por otro rango o un bastión olvidado son suficientes para hacer que la regla quede inoperante.
No abras 0.0.0.0/0 hacia el puerto 8006 como configuración normal. Esta amplia excepción solo se justifica en un laboratorio aislado y asumido, no en un nodo de producción accesible a distancia.
Autorizar Web UI y SSH a nivel de host
Los dos accesos de administración que se deben tratar primero son la Web UI de Proxmox en TCP 8006 y SSH en TCP 22. Coloca las reglas a nivel de host o Datacenter según tu organización, reutilizando el IPSet +management.
[RULES]
IN ACCEPT -source +management -p tcp -dport 8006
IN ACCEPT -source +management -p tcp -dport 22Este bloque ilustra reglas de entrada específicas. Mantén la política de entrada permisiva durante la primera prueba si el IPSet aún no se ha verificado. El endurecimiento viene después de la prueba de acceso, no antes.
SPICE utiliza TCP 3128 y la consola VNC Web utiliza TCP 5900-5999. Agrega estas necesidades solo si tu administración las usa realmente. En un clúster, no interrumpas tampoco Corosync sobre UDP 5405-5412 ni la migración sobre TCP 60000-60050.
El IPSet management se refiere a los hosts. No configura las reglas de las VM y contenedores. Las reglas IN y OUT detalladas de los invitados siguen siendo otro trabajo.
Compilar, simular, y luego activar un solo nivel
Antes de la activación, muestra las reglas compiladas:
pve-firewall compile
pve-firewall statuspve-firewall status vuelve a leer y compila la configuración completa. Las advertencias que se muestran deben ser tratadas antes del cambio. Una compilación limpia no prueba aún que tu fuente remota pueda unirse a 8006 o 22, pero un error de configuración puede detener la secuencia.
Luego puedes simular los dos accesos de administración con la dirección real del administrador y la del nodo:
pve-firewall simulate --from outside --to host --source <IP_ADMIN> --dest <IP_NOEUD> --dport 8006 --protocol tcp
pve-firewall simulate --from outside --to host --source <IP_ADMIN> --dest <IP_NOEUD> --dport 22 --protocol tcpLa simulación prueba las reglas con la fuente, el destino, el puerto y el protocolo proporcionados. No simula la tabla de enrutamiento del núcleo. Por lo tanto, un resultado favorable no reemplaza ni a la consola de rescate ni a una prueba real desde una nueva conexión.
Luego activa Datacenter o Node, un solo nivel a la vez, desde Datacenter > Firewall o Node > Firewall. Si usas el archivo del clúster, la activación documentada se escribe así:
[OPTIONS]
enable: 1No pases directamente a los archivos de VM. El primer cambio debe responder a una sola pregunta: ¿se puede seguir alcanzando el acceso de administración del nodo desde la fuente autorizada?
Probar con una nueva conexión
Después de la activación, abre una nueva ventana y carga https://<ip-noeud>:8006/. También inicia una nueva sesión SSH desde la fuente ubicada en management. La sesión antigua permanece abierta durante estos dos controles.
Luego, revisa el estado del firewall:
pve-firewall statusEn el antiguo backend, iptables-save permite leer las reglas generadas. Úsalo para observar, no para editar directamente las cadenas producidas por Proxmox. El artículo sobre la lectura de las reglas iptables en Linux cubre este control de bajo nivel.
Cierra la sesión antigua solo después de validar la Web UI y una nueva conexión SSH. Si la prueba falla, utiliza la consola independiente para eliminar la regla problemática o desactivar la opción a nivel activado.
Atención: pve-firewall stop elimina activamente las reglas de Proxmox VE relacionadas con iptables. El host puede quedar entonces sin protección. Es un gesto de recuperación limitado, no un estado final recomendado.
Detenerse antes de las reglas de VM
A este punto, has asegurado el orden de activación y verificado el acceso de administración del nodo. Detente aquí si tu objetivo era implementar el firewall de Proxmox sin bloqueo.
- Las reglas detalladas de las VM y contenedores son un tema dedicado a las reglas de firewall de VM Proxmox.
- Una red bloqueada requiere un diagnóstico separado, con su propio ámbito y controles.
- La lectura detallada de los logs del firewall será objeto de otro artículo.
- El caso de un acceso SSH ya bloqueado no debe mezclarse con esta activación preventiva.
El backend nftables proxmox-firewall sigue siendo una vista técnica según la documentación oficial, con posibles errores o incompatibilidades. No lo elijas como vía de producción para esta primera activación.
Si posteriormente una VM pierde su conectividad, el diagnóstico ya no se refiere al acceso de administración del nodo. Entonces hay que retomar el tema de red de la VM en el artículo dedicado a la tarjeta de red virtual Proxmox.