Cuando el firewall no responde: cómo bloquear el puerto 8006 en Proxmox

Empezó como una prueba inofensiva, o al menos eso creía él. Un aficionado al homelab con Proxmox VE en un entorno modesto pero bien afinado quiso bloquear el acceso a su interfaz de gestión. Nada sofisticado, solo una comprobación rápida del firewall. El objetivo era impedir que cualquiera pudiera acceder a la GUI de Proxmox por el puerto 8006, incluso desde dentro de la red local.

Al firewall pareció darle igual. Sin importar qué reglas añadiera ni lo impecable que pareciera la sintaxis, el puerto 8006 de Proxmox seguía aceptando conexiones. Cada intento de denegar el acceso devolvía un éxito burlón: la página de inicio de sesión seguía cargando sin inmutarse. Para una configuración pensada para simular un entorno de producción blindado, resultaba desesperante.

Si alguna vez has trasteado con virtualización, sobre todo en homelabs, esto probablemente te resulte familiar. Empiezas con una instalación limpia de Proxmox, quizá virtualizas pfSense como router o firewall y, antes de que te des cuenta, te ves persiguiendo fantasmas entre reglas de iptables e interfaces bridge. El momento en que descubres que tu firewall no hace lo que debería es cuando empieza la depuración de verdad.

La prueba que debería haber sido sencilla

El montaje era directo:

• pfSense virtualizado dentro de Proxmox VE.
• enp1s0 actuando como interfaz WAN.
• enp2s0 y enp3s0 vinculadas en bond para la LAN.
• Un espacio de direccionamiento privado con 10.10.0.0 para pruebas del lado WAN y 10.0.0.0 para la LAN.

El usuario, al intentar simular un acceso externo, escribió reglas dentro de /etc/pve/nodes/proxmox/host.fw como esta:

IN REJECT -i enp1s0 -source 10.10.0.25 -dest 10.10.0.10 -p tcp -dport 8006 -log nolog

y

IN REJECT -i vmbr0 -source 10.10.0.25 -dest 10.10.0.10 -p tcp -dport 8006 -log nolog

El objetivo era rechazar todo el tráfico TCP dirigido al puerto 8006, que es el puerto predeterminado de Proxmox para la GUI web.

El resultado no coincidió con la intención. Incluso después de habilitar el firewall de Proxmox, la GUI seguía accesible, y la máquina de pruebas en 10.10.0.25 aún podía iniciar sesión en el panel web del host como si nada hubiera cambiado.

«Todavía puedo acceder al puerto 8006 desde el origen 10.10.0.25», escribió el usuario. «Solo quiero saber si me estoy perdiendo algo. ¿Quizá el acceso al puerto de Proxmox VE se está permitiendo por defecto en algún otro sitio?».

Los puertos que crees conocer

Para la mayoría de los usuarios, los puertos de Proxmox son fáciles de recordar: el 8006 para la GUI, el 22 para SSH y quizá algunos más para la comunicación del clúster o la consola SPICE. Lo que suele pasarse por alto es cómo gestiona Proxmox esos puertos a nivel interno.

El puerto 8006 corresponde a pveproxy, un demonio que reside en lo profundo de la pila de gestión. Se ejecuta como un servicio del sistema y se enlaza a todas las interfaces disponibles en lugar de escuchar en una sola. De este modo, aunque creas estar aplicando una regla para bloquear vmbr0, pveproxy puede seguir escuchando en otros bridges o adaptadores en bond del host.

Por diseño, Proxmox VE presupone que su interfaz de gestión debe ser siempre accesible desde cualquier red conectada, al menos hasta que le indiques lo contrario en una capa superior o la aísles por completo mediante VLANs o una subred exclusiva de gestión.

Por eso el primer consejo de la comunidad fue rotundo: «10.10.0.10 no es una dirección WAN, sigue siendo una dirección LAN. Si quieres controlar el acceso a la GUI web de Proxmox desde tu LAN, arréglalo con el firewall interno. Pero si quieres bloquear el acceso desde internet, ese es el trabajo de pfSense».

Fue un buen recordatorio de que los «puertos bloqueados» tienen matices. Dentro de una pila de virtualización, el host, el invitado y los bridges virtuales gestionan el tráfico de manera distinta, por lo que el tráfico que crees haber cortado en un nivel puede seguir colándose por otra capa.

Capa sobre capa: cuando los firewalls virtuales chocan

Ejecutar pfSense dentro de Proxmox crea el dilema clásico del huevo y la gallina. Proxmox gestiona las máquinas virtuales, pero pfSense gestiona la red de la que se nutre el propio Proxmox.

En este caso de prueba, el host de Proxmox se situaba detrás de pfSense, lo que significa que pfSense no controlaba en realidad el tráfico hacia Proxmox, sino solo el tráfico que pasaba a través de él. Por eso intentar bloquear el puerto 8006 de Proxmox desde pfSense no tenía mucho sentido. La única solución real era conseguir que el propio firewall de Proxmox (pve-firewall) colaborase, y ahí fue donde empezó el desconcierto.

Varios usuarios en el hilo señalaron que el firewall a nivel de host de Proxmox tiene sus peculiaridades:

• Tienes que comprobar que esté habilitado de forma global (pvefirewall status).
• Debes confirmar que las reglas se apliquen sobre la interfaz correcta.
• Y quizá lo más importante: las reglas se evalúan en orden, lo que significa que si una regla ACCEPT superior permite la conexión, la regla REJECT inferior no tendrá efecto.

Un comentario útil recomendó activar el registro en las reglas REJECT con -j LOG para comprobar si llegaban a dispararse. Spoiler: no lo hacían. Resultó que el orden de las reglas o la asignación de interfaces estaba mal planteada, un tropiezo sutil pero muy frecuente al trabajar con los bridges virtuales de Proxmox.

Las VLAN al rescate (casi siempre)

Otro usuario intervino con una recomendación veterana: coloca la interfaz de gestión en una VLAN dedicada. De este modo, Proxmox VE dispondría de una red exclusiva de gestión, separada de la utilizada por las máquinas virtuales o la LAN.

«Yo pondría la GUI de Proxmox en una VLAN de gestión independiente», escribió un participante.

La idea es que incluso si cometes un fallo en las reglas del firewall, los clientes de tu LAN principal no tendrán ruta hacia la interfaz de administración. Es una separación física aplicada de forma lógica.

Esto conllevaba sus propias dificultades. El autor del hilo indicó que cuando su router caía, acceder a la VLAN de gestión se volvía casi imposible, sobre todo si dependía de ese mismo router para enrutar el tráfico entre VLANs.

¿La respuesta? «Deja un puerto libre para conectarte por cable a tu VLAN de gestión para resolver problemas». En otras palabras: cuenta siempre con un plan de contingencia. Si pierdes el enrutamiento, todavía puedes conectarte directamente a la red y acceder al panel de Proxmox, porque en un homelab, e incluso en entornos pequeños de producción, no hay nada peor que quedarse fuera de tu propio hipervisor.

Por qué bloquear puertos en Proxmox es más difícil de lo que parece

A primera vista, bloquear un puerto en Proxmox parece tan sencillo como redactar una regla de firewall. Sin embargo, Proxmox no se comporta como un servidor Linux tradicional. Además de sus propias interfaces, gestiona bridges virtuales, túneles y canales de comunicación del clúster.

Por tanto, cuando crees estar apuntando al puerto de la GUI (8006), quizá también debas tener en cuenta:

• El enlace de interfaz para pveproxy
• Los puertos de sincronización del clúster (normalmente del 5400 al 5405)
• SSH (puerto 22) para la gestión del nodo
• Los puertos de migración de QEMU (rango de 60000 a 60050)
• Y los puertos de consola para SPICE o noVNC

Los puertos de Proxmox dependen unos de otros. Cerrar uno sin cuidado puede romper fácilmente otro servicio o, peor aún, dejarte fuera del sistema por completo.

Por eso los administradores experimentados aconsejan un enfoque por capas:

• Utiliza pfSense u otro firewall perimetral para bloquear el acceso externo.
• Configura el firewall de Proxmox VE para la segmentación interna.
• Y si es posible, mantén el tráfico de gestión aislado mediante VLANs o interfaces dedicadas.

Si todo lo demás falla, puedes enlazar la interfaz web de Proxmox a una dirección IP concreta editando /etc/default/pveproxy y reiniciando el servicio. La mayoría de los usuarios de homelab no piensan en esa opción, pero es un recurso sólido si el puerto predeterminado de Proxmox sigue exponiéndose a redes indebidas.

La perspectiva general: control frente a comodidad

Que un puerto de Proxmox se resista a cerrarse es un pequeño ejemplo de la tensión entre control y comodidad que define a tantas infraestructuras actuales.

La virtualización promete control absoluto: entornos aislados, reglas claras y una predictibilidad perfecta. En la práctica es más desordenada. Cuantas más capas añades (hipervisor, firewall virtual, VLANs), más fácil resulta perder la pista de quién controla de verdad el flujo de tráfico.

Para los aficionados al homelab, eso forma parte tanto de la diversión como de la frustración. Aprendes rompiendo cosas. Pasas horas depurando un puerto abierto en Proxmox VE solo para descubrir que un demonio escuchaba en todas las interfaces por defecto. Ajustas VLANs, pruebas esquemas de HA y con el tiempo construyes un mapa mental nítido de cómo funciona tu red.

Al final, el «firewall que no hacía caso» es un rito de iniciación para muchos aficionados al homelab. Cuando has batallado con los puertos de Proxmox el tiempo suficiente, descubres que los archivos de configuración solo te llevan hasta la mitad del camino: el resto exige comprender cómo encaja todo tu mundo virtual.

Reflexiones finales

La ironía de toda esta historia es que nació como una simple prueba. Una sola regla pensada para bloquear un único puerto de Proxmox se transformó en un curso intensivo de segmentación de redes, gestión de VLANs y funcionamiento interno del firewall de un hipervisor.

Proxmox VE es una herramienta potente, pero no hace magia. El puerto predeterminado 8006 de Proxmox está abierto por un buen motivo: es el salvavidas del sistema. Cerrarlo con seguridad y criterio requiere algo más que una regla de firewall; exige entender cómo conecta la arquitectura de Proxmox cada una de sus piezas.

Así que la próxima vez que un puerto de Proxmox se niegue a cerrarse, no te lo tomes como algo personal. Es solo la plataforma recordándote que una red virtual puede seguir generando problemas muy reales.