Proxmox + OPNsense: diseño completo de red, firewall, VLANs y servidores

agosto 3, 2026 Alfonso Moreno | Sysadmin Senior 102 Visitas 11 min de lectura

Hay dos formas razonables de montar Proxmox con OPNsense: firewall físico dedicado o firewall virtualizado dentro del propio hypervisor. Cada una tiene sus compromisos. Esta guía las compara, propone un diseño para cada caso y termina con un plan de recuperación para cuando (no si) algo se rompe.

TL;DR — Lo que vas a tener al final

Tiempo de setup: 2-3 horas para el switch a enforcing.
Requisitos: Root, kernel moderno, 2-4 semanas en permissive antes de enforcing.
Resultado: Sistema con MAC activo, logs en /var/log/audit/audit.log.
Troubleshooting: audit2allow, audit2why, setenforce 0 para emergencias.

1. El debate físico vs virtual

OPNsense físico (appliance aparte) sobrevive si Proxmox cae y suma una caja más al inventario. OPNsense virtualizado en Proxmox puede abaratar el montaje, facilita los snapshots, pero convierte al host en un punto único de fallo.

La decisión depende de presupuesto, tolerancia al downtime y complejidad. La mayoría empieza virtualizado por simplicidad y migra a físico cuando el homelab crece.

2. Diseño A: OPNsense físico

Para esta topología necesitas al menos dos interfaces de red fiables (WAN y LAN/trunk) y almacenamiento persistente. CPU y RAM dependen del caudal, las VPN y si activarás IDS/IPS; usa la tabla de hardware oficial de OPNsense como punto de partida. Evita depender de un adaptador USB-Ethernet para la WAN cuando una NIC interna bien soportada sea posible.

Topología:

[ISP router] --WAN-- [OPNsense] --LAGG trunk-- [Switch gestionable] -- [APs, NAS, Proxmox, resto]

Proxmox se conecta al switch por una boca y forma parte de la VLAN de servidores. El trunk entre el switch y OPNsense lleva todas las VLANs, mientras que la boca de Proxmox puede ser untagged en la VLAN SERVERS o tagged en varias, según cuántos segmentos necesite ver el hypervisor.

                +-------------------+
                |     OPNsense      |
                |   (físico)        |
                +---------+---------+
                          | LAGG trunk (VLANs 10,20,30,40)
                          v
                  +---------------+
                  | Switch L2+    |
                  +-------+-------+
                          |
        +---------+-------+-------+----------+
        |         |       |       |          |
   VLAN 10    VLAN 20  VLAN 30  VLAN 40    trunk
   (LAN)      (SRV)    (GUEST)  (IOT)    (Proxmox vmbr)
        |         |
     [AP WiFi] [Proxmox VE] -> VMs

3. Diseño B: OPNsense virtualizado en Proxmox

Aquí todo vive en una sola caja. Proxmox arranca, levanta una VM con OPNsense que tiene dos interfaces: una WAN bridged a la NIC física conectada al ISP, y una LAN bridged a otra NIC o a un VLAN-aware bridge del propio Proxmox.

Topología:

[ISP router] --WAN-- [Proxmox host] --vmbr0 (WAN)-- [VM OPNsense] --vmbr1 (VLAN-aware trunk)-- [VMs, switch opcional]

        +--------------------------------+
        |         Proxmox VE host        |
        |  +-------------------------+   |
        |  |  VM OPNsense            |   |
        |  |  net0 = vmbr0 (WAN)     |   |
        |  |  net1 = vmbr1 (VLANs)   |   |
        |  +-------------------------+   |
        |                                |
        |  otras VMs usan vmbr1 con tag  |
        |  (VLAN 10, 20, 30, 40...)      |
        +--------------+-----------------+
                       | vmbr0 (WAN)
                       v
                  [ISP router]

Proxmox configura el bridge vmbr1 como VLAN-aware y todas las VMs reciben tráfico con tag de la VLAN correspondiente. La documentación oficial Network Configuration lo explica al detalle: un bridge Linux se comporta como un switch virtual, y marcarlo como VLAN-aware le añade el soporte 802.1Q.

4. El switch gestionable: la pieza que conecta las VLANs

Cualquiera de los dos diseños necesita un switch que entienda 802.1Q. La razón es que la segmentación de VLANs vive ahí, no en Proxmox. Proxmox puede crear VLANs internas, pero a la hora de separar tráfico físico necesitas un switch que etiquete y desetiquete tramas en los puertos access.

Reglas de cableado:

Uplink OPNsense → switch: trunk, todas las VLANs taggeadas, sin VLAN nativa (siguiendo la guía oficial de OPNsense para VLANs).
Puerto Proxmox → switch: depende del diseño. En el diseño B, trunk con todas las VLANs que las VMs necesitan. En el diseño A, puede ser access a SERVERS o trunk si quieres que las VMs vivan en VLANs distintas.
Puertos de usuarios: access a la VLAN 10 (LAN).
Puerto AP: trunk mixto con VLAN 10 untagged (gestión) y las VLANs de invitados/IoT taggeadas.

5. Topología de VLANs que vamos a usar

Las cuatro VLANs de la serie, con subredes que no se solapan:

VLAN ID	Nombre	Subred	Gateway	Función
10	LAN	10.10.10.0/24	10.10.10.1	Equipos de gestión y usuarios
20	SERVERS	10.10.20.0/24	10.10.20.1	Proxmox, NAS, OPNsense si virtualizado
30	GUEST	10.10.30.0/24	10.10.30.1	WiFi invitados
40	IOT	10.10.40.0/24	10.10.40.1	Dispositivos IoT

Las IPs concretas son ejemplos. Lo importante es que cada VLAN tenga su subred propia, que la IP de gestión de OPNsense esté en SERVERS y que la IP de gestión de Proxmox también viva en SERVERS. Si la gestión está en LAN, un invitado curioso tiene más fácil llegar hasta tu hypervisor.

6. Diseño A paso a paso: Proxmox + OPNsense físico

6.1 El bridge de Proxmox

Si Proxmox solo necesita una VLAN (SERVERS), el bridge es trivial:

auto lo
iface lo inet loopback
auto eno1
iface eno1 inet manual
auto vmbr0
iface vmbr0 inet static
    address 10.10.20.50/24
    gateway 10.10.20.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0

Si quieres que Proxmox gestione VMs en varias VLANs, marca el bridge como VLAN-aware y configura los tags por VM en la GUI de Proxmox.

6.2 Reglas firewall sugeridas

En OPNsense, sobre el alias Servers que apunta a 10.10.20.0/24:

#	Acción	Origen	Destino	Puerto	Notas
1	Pass	Servers net	any	80, 443	Actualizaciones
2	Pass	LAN net	Servers net	*	Administración
3	Pass	WireGuard net	Servers net	*	VPN
4	Pass	Servers net	DNS	53	Resolver local
5	Block	Guest net	Servers net	*	Aislar
6	Block	IoT net	Servers net	*	Aislar

Las dos últimas reglas reflejan el principio básico: las VLANs de invitados e IoT no tienen nada que hacer hablando con servidores.

7. Diseño B paso a paso: OPNsense como VM de Proxmox

7.1 Bridges en Proxmox

Dos bridges mínimo:

# /etc/network/interfaces
auto lo
iface lo inet loopback
# WAN: una NIC física va al ISP
auto eno1
iface eno1 inet manual
auto vmbr0
iface vmbr0 inet manual
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0
# LAN: la otra NIC o un alias que será trunk VLAN-aware
auto eno2
iface eno2 inet manual
auto vmbr1
iface vmbr1 inet manual
    bridge-ports eno2
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 10 20 30 40

La línea bridge-vlan-aware yes es la que activa 802.1Q en el bridge. bridge-vids 10 20 30 40 declara qué VLANs se permiten.

7.2 VM OPNsense

Crea una VM con:

CPU: 2 cores, type host (expone todas las instrucciones del CPU físico al guest; es el type recomendado para OPNsense)
RAM: 2 GB mínimo, 4 GB si activas IDS/IPS o VPN con muchos túneles
Disco: 32 GB VirtIO SCSI, espacio para actualizaciones, logs y configuración
Red: dos NICs VirtIO — net0 en vmbr0 (WAN), net1 en vmbr1 (LAN/trunk)
Boot: desde la ISO de OPNsense, instalación estándar
Arranque: marcar “Start at boot” y, en Proxmox, configurar el orden para que OPNsense arranque antes que las VMs que dependen de él

Importante: el bridge WAN debe quedar sin dirección IP en el host. Solo la NIC virtual WAN de OPNsense debe usarlo; las demás VMs no deben conectarse a ese bridge.

7.3 Gestión de Proxmox fuera de VLAN peligrosa

La gestión de Proxmox no debería vivir en la VLAN LAN: si un día configuras mal las reglas y dejas la LAN expuesta, la gestión del hypervisor cae con ella. La práctica recomendada:

Crear una VLAN de gestión (por ejemplo 99) con alias solo accesible desde VPN o desde la LAN.
Limitar el acceso a la GUI de Proxmox (puerto 8006) por firewall, no solo por contraseña.
Activar 2FA. Cambiar el puerto por defecto no sustituye autenticación fuerte ni reglas de acceso.

La documentación oficial de Proxmox insiste en que la gestión de red del host debe planearse: una configuración incorrecta puede dejarte sin acceso. La GUI prepara cambios en /etc/network/interfaces.new; el botón Apply Configuration los mueve al archivo activo y usa ifupdown2 para recargar. Eso no garantiza una reversión automática si pierdes conectividad. Conserva consola local o gestión fuera de banda y revisa el diff antes de aplicar.

8. Orden de las reglas de firewall

Las reglas se procesan arriba abajo; la primera que casa gana. Una política razonable y fácil de mantener:

Anti-spoofing y bloqueo de redes privadas o bogons en WAN cuando corresponda al tipo de conexión.
Reglas específicas en la interfaz por la que entra el tráfico, con origen, destino y puerto mínimos.
Permisos de DNS, NTP y servicios de infraestructura antes de los bloqueos generales.
Default deny implícito para lo que no coincida con una regla permitida.
Logging selectivo en reglas de bloqueo que necesites diagnosticar, sin inundar el disco.

El artículo sobre firewall Linux con nftables explica la misma lógica en chains nftables, útil si tienes reglas en máquinas Linux detrás de OPNsense y quieres coherencia.

9. Evitar el single point of failure

Un homelab bien montado no debería depender de una sola caja. Tres medidas:

Doble OPNsense con CARP si tienes dos appliances o dos hipervisores. OPNsense soporta HA con IP flotante y sincronización de configuración. La doc oficial de WireGuard marca el campo “Depend on (CARP)” para que el túnel solo se levante en el nodo maestro.
Segundo nodo y copias restaurables para cargas críticas. Ceph necesita un diseño de clúster y quórum apropiado; no lo presentes como arreglo rápido para dos nodos.
Switch gestionable con VLANs independientes: si OPNsense cae en el diseño A, el switch sigue pasando tráfico dentro de cada VLAN (no hay inter-VLAN, pero los equipos siguen funcionando entre sí).

En el diseño B, el SPOF es más obvio: si Proxmox cae, cae todo. La mitigación pasa por tener un segundo nodo Proxmox que pueda levantar las VMs críticas, incluido el propio OPNsense. Los dos nodos comparten almacenamiento (NFS, Ceph, iSCSI) y forman un clúster.

10. Plan de recuperación cuando algo se rompe

Toda esta arquitectura se viene abajo el día que cambias una regla y te quedas sin acceso. El plan mínimo:

Acceso de consola: tener un teclado y monitor conectados al servidor Proxmox o al appliance OPNsense. En Proxmox, la consola física (VGA/HDMI) sigue siendo la red de seguridad definitiva.
Backup de configuración: OPNsense exporta su config en System ‣ Configuration ‣ Backups. Proxmox tiene su propio sistema de backup. Una copia semanal fuera del propio servidor (NAS, nube, USB) salva el día.
Documentar los cambios: cada vez que toques una regla de firewall, anótala. Un cuaderno o un git con un markdown basta.
Snapshots antes de tocar: en Proxmox, snapshot de la VM OPNsense antes de cualquier cambio. Si te equivocas, vuelves a ese snapshot en un minuto.
Pruebas de restore: una copia que nunca se ha restaurado no es una copia. Programa una vez al mes un restore en una VM de pruebas para verificar que el backup funciona.
Watchdog hardware: en Proxmox activa el watchdog por software (systemctl enable watchdog). Si la VM OPNsense se cuelga en el diseño B, el host puede reiniciarla.

11. Monitorización y seguridad por capas

Para no enterarte tres días después de que OPNsense se cayó, monta un stack de monitorización con Grafana y Prometheus. Los exporters que tienen sentido: uno compatible con la API de Proxmox, métricas de OPNsense y snmp_exporter en el switch. Ajusta las alertas a la línea base de tu hardware: disponibilidad del firewall, saturación sostenida del host, espacio de almacenamiento y temperatura fuera del rango normal del equipo.

La seguridad real se construye por capas, no por un solo producto:

Capa 1: red segmentada. VLANs, firewall, reglas por defecto deny.
Capa 2: inspección. Suricata en modo IDS, alertas a un SIEM.
Capa 3: VPN. Acceso remoto con WireGuard, no con SSH a la WAN.
Capa 4: actualizaciones. Proxmox y OPNsense con updates automáticas, OPNsense con firmware unattended.
Capa 5: backups. Lo único que de verdad rescata el homelab cuando todo lo demás falla.

El firewall Linux con nftables entra en juego en las VMs Linux: por mucho que OPNsense filtre, cada servidor debería tener su propio firewall local por si el routing cambia o por si una VM se mueve a otra VLAN.

Conclusiones

Proxmox con OPNsense da para un homelab completo: virtualización, firewall, segmentación, VPN y monitorización en la misma caja o en dos, según el gusto. La clave no es el hardware, sino la disciplina: VLANs claras, reglas ordenadas, gestión fuera de la VLAN de usuarios, backups probados y un plan de recuperación escrito. Si tienes eso, cualquier fallo se resuelve en minutos. Si no lo tienes, cualquier cambio se convierte en una pesadilla.

Preguntas frecuentes

¿Por qué Proxmox + OPNsense: diseño completo de red, firewall, VLANs y servidores es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Proxmox + OPNsense: diseño completo?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Proxmox + OPNsense: diseño completo?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Proxmox + OPNsense: diseño completo y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Proxmox + OPNsense: diseño completo?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.