Ejecutar OPNsense como VM firewall en Proxmox

Primero la respuesta: cuándo tiene sentido un firewall virtual

Ejecutar OPNsense como guest de Proxmox es un patrón muy transitado y viable en producción, con un perfil claro de cuándo es la decisión correcta:

Hazlo cuando el trabajo del firewall sea proteger el parque virtual: una VM de OPNsense como gateway para tus demás guests te da routing inter-VLAN, una DMZ como es debido, terminación VPN e IDS/IPS para todo lo que hay detrás, además de los dividendos de la virtualización: snapshot antes de cada actualización, restauración de configuración en minutos, y ningún segundo chasis que alquilar. En un único servidor dedicado que aloja muchas VM, es el diseño natural.

Piénsalo dos veces cuando el firewall deba ser independiente del hipervisor (si OPNsense es el perímetro para infraestructura más allá de este host, cada reinicio de Proxmox se lleva tu red por delante) o cuando necesites hasta el último gigabit con offloads de hardware, donde el bare metal (o el passthrough de NIC) todavía tiene ventaja.

Una regla de diseño por adelantado, aprendida por las malas por todo el que se la saltó: nunca hagas que la propia interfaz de gestión del host Proxmox dependa de la VM de OPNsense. El SSH/UI web del host debe seguir siendo alcanzable por su propia ruta; de lo contrario, una VM firewall que no arranca te deja fuera del propio hipervisor desde el que la arreglarías. (El KVM-over-IP es el respaldo, pero no diseñes contando con necesitarlo.)

Diseño de red en un servidor dedicado

Esto se apoya directamente en el modelo de bridges de nuestra guía de redes de Proxmox. OPNsense se convierte simplemente en un guest con una pata en dos (o más) bridges:

WAN: una NIC virtual en vmbr0 (el bridge público), configurada con una IP pública adicional asignada a tu servidor, respetando la política MAC del proveedor, exactamente igual que para cualquier guest en bridge. En nuestra red, las IP adicionales vienen incluidas con el servidor y esto funciona sin más.
LAN: una NIC virtual en un bridge interno (bridge-ports none, un switch sin uplink, por ejemplo vmbr1). Cada guest que deba vivir detrás del firewall se conecta aquí y usa la dirección LAN de OPNsense como gateway.
Más segmentos: más bridges internos, o (más limpio a escala) un único bridge interno compatible con VLAN donde OPNsense toma un trunk y enruta entre segmentos etiquetados. Eso te da una DMZ, una red de gestión y un laboratorio, todos protegidos por firewall en un único punto.

El propio host Proxmox mantiene su IP de gestión en vmbr0 (o mejor, en una interfaz de gestión dedicada), no detrás de la VM de OPNsense, según la regla anterior. Los guests obtienen defensa en profundidad: nuestro firewall de borde de red upstream, OPNsense en el límite del segmento, y reglas en el propio host dentro de cada guest donde esté justificado.

La configuración de VM que funciona

La comunidad (y el HOWTO de virtualización, bien mantenido, del foro oficial de OPNsense) ha convergido en una receta; desviarse de ella es donde viven los bugs misteriosos:

Ajuste	Valor	Por qué
Machine / firmware	q35, OVMF (UEFI) o SeaBIOS	Ambos van bien; con OVMF, desmarca "Pre-Enroll keys": OPNsense no admite Secure Boot
CPU	2–4 vCPU, tipo host	FreeBSD se beneficia de flags de CPU reales; cores según la nota de dimensionamiento de abajo
RAM	4–8 GB, ballooning desactivado	FreeBSD y el ballooning no combinan bien; el ZFS del guest aprovecha el extra
Disco	40 GB+ VirtIO SCSI, ZFS en el instalador	ZFS-on-root es la opción fiable para una máquina que snapshoteas y apagas de golpe
NIC	VirtIO (paravirtualizada), una por bridge	La opción preferida actualmente (ver la nota de offloading)
Guest agent	Instala el plugin `os-qemu-guest-agent`, actívalo en las opciones de la VM	Apagados limpios, visualización de IP, snapshots consistentes
Orden de arranque	Arranca primero, antes que los guests detrás	Su gateway debe existir cuando ellos arranquen

Honestidad sobre el dimensionamiento: las recomendaciones oficiales de hardware de OPNsense topan sus niveles en "750+ Mbit/s" para la spec "recommended" de 8 GB, y no publican una cifra exacta de gigabit virtualizado; la receta de 2–4 vCPU / 4–8 GB es una guía establecida por la comunidad, cómoda para enrutar un gigabit con un ruleset normal. La RAM de la state-table rara vez es el problema (aproximadamente 1 KB por estado de conexión); el IDS/IPS de Suricata sí lo es: la inspección inline consume mucha CPU y es lo que empuja a una VM firewall pequeña hacia 4+ cores.

La nota sobre offloading que te ahorra un fin de semana

Dolor histórico: las NIC VirtIO más el offload de checksum por hardware en guests FreeBSD causaban paquetes perdidos y conectividad rota. El OPNsense moderno ya trae la respuesta correcta: el offloading de checksum/TSO/LRO por hardware está desactivado por defecto (Interfaces → Settings). Así que el consejo práctico en 2026 es: verifica que esas casillas sigan marcadas ("disable") y no las "optimices" reactivándolas en interfaces VirtIO. Si una VM de OPNsense pasa el tráfico de forma rara (algunos sitios cargan, otros se cuelgan), este ajuste es el sospechoso número uno.

Instalación, en resumen

Sube la ISO del instalador de OPNsense (serie actual: 26.1; el proyecto lanza dos versiones mayores al año, en enero y julio) a Proxmox y arranca la VM desde ella.
Inicia sesión como installer, instala en disco eligiendo ZFS, reinicia.
En la consola, asigna las interfaces: las NIC VirtIO aparecen como vtnet0, vtnet1… Hazlas coincidir con WAN/LAN mediante las direcciones MAC que muestra el panel de hardware de Proxmox (ponlas memorablemente distintas al crear la VM; tu yo futuro te lo agradecerá).
Configura WAN con tu IP pública/gateway asignada y LAN con tu rango interno (por ejemplo 10.0.0.1/24), luego abre la interfaz web desde un guest en el bridge LAN (o mediante un túnel SSH a través del host) y ejecuta el asistente de configuración.
Primeros pasos tras el asistente: actualizar a la versión actual, instalar os-qemu-guest-agent, tomar tu primer snapshot.

Es en la operación del día a día donde brilla el formato VM: snapshot → actualizar → verificar → borrar snapshot convierte las versiones mayores semestrales de OPNsense de un riesgo de mantenimiento en un no evento, y PBS respalda todo el firewall cada noche como cualquier otro guest.

¿Y qué pasa con pfSense?

La misma receta se aplica casi al pie de la letra a pfSense, también FreeBSD, también cómodo con VirtIO. Entre los dos: pfSense CE sigue vivo (2.8.x actual, 2.9 en desarrollo) junto al pfSense Plus comercial, mientras que la cadencia predecible de dos versiones mayores al año de OPNsense, su modelo totalmente abierto y su interfaz moderna lo han convertido en la recomendación por defecto en el mundo del self-hosting estos últimos años. Si ya conoces uno, úsalo; si empiezas de cero, esta guía eligió OPNsense a propósito.

Preguntas frecuentes

¿Debería hacer passthrough de una NIC física a OPNsense en lugar de usar VirtIO?

Usa VirtIO por defecto: es la recomendación actual de la comunidad, mantiene la VM completamente virtual (snapshots, migración, sin líos con IOMMU) y enruta un gigabit sin problemas. El passthrough PCI justifica su complejidad en dos casos: perseguir el máximo throughput con offloads de hardware en enlaces multi-gigabit, o querer el cable WAN físicamente aislado de la pila de red del hipervisor. Si haces passthrough, la VM pierde la migración en vivo y la comodidad de los snapshots. Ahí renuncias precisamente a las razones para virtualizar.

¿OPNsense protege también el host Proxmox?

No en este diseño. Y no debería. El plano de gestión del host se mantiene en su propia ruta (deliberadamente no detrás de la VM firewall), protegido en cambio por el firewall perimetral upstream, sus propias reglas, y por no exponer nunca la interfaz web (puerto 8006) públicamente. Enrutar el tráfico propio del host a través de un guest que él mismo aloja crea una dependencia circular con exactamente un modo de fallo: bloqueo total. Guests detrás de OPNsense; host al lado, protegido de forma independiente.

¿Cuánto rendimiento pierdo frente a bare metal?

Para routing/NAT simple a escala de gigabit en cores modernos: lo bastante poco como para que gane la comodidad de VirtIO: los niveles de spec oficiales sitúan incluso al hardware modesto en la clase "750+ Mbit/s", y una VM bien configurada se sitúa en esa banda. Los costes honestos aparecen en los extremos: el throughput multi-gigabit (el overhead por paquete de la red paravirtualizada se acumula; considera passthrough) y el IDS/IPS (la inspección de Suricata es la verdadera factura de CPU, se ejecute donde se ejecute). Mide tu propia ruta antes de optimizar, y consulta el benchmark de la redacción más arriba.

¿Puedo ejecutar esto en alta disponibilidad?

CARP (el failover al estilo VRRP de OPNsense) funciona virtualizado, pero piensa bien qué te aporta en un solo host: dos VM firewall en el mismo hipervisor comparten todos los modos de fallo de hardware, así que el CARP intra-host cubre sobre todo ventanas de actualización, que los snapshots ya cubren. La HA real de firewall significa VM de OPNsense en dos hosts con los segmentos LAN extendiéndose entre ellos (VLAN sobre red privada, o VXLAN vía Proxmox SDN), algo que vale la pena cuando los guests detrás justifican un diseño de nivel cluster en general.

Desplegar en Serverside

Todo lo que necesita este patrón viene incluido aquí con un servidor dedicado Proxmox: IP públicas adicionales para la pata WAN, red privada que lleva tus VLAN entre hosts para los diseños multiservidor, mitigación DDoS siempre activa por delante de todo el conjunto, y KVM-over-IP como respaldo contra el bloqueo total. Proxmox viene preinstalado; la ISO de OPNsense está a un solo upload de distancia.

Complétalo con la guía a fondo de redes de Proxmox sobre la que se apoya este diseño, las estrategias de backup para la propia VM firewall, y (para la alternativa WireGuard-native en la capa de routing) nuestra guía de sitio a sitio con VyOS.