Problema

Muchos entusiastas de homelab intentan replicar entornos empresariales usando equipos de gama alta, pero el presupuesto y el espacio a menudo son limitados. El desafío recurrente es lograr una arquitectura de red segmentada (VLANs, routing inter‑VLAN, políticas de firewall) sin depender de switches y routers costosos. En la práctica, el cuello de botella suele estar en el router doméstico de 100 Mbps, que no soporta VLAN tagging ni reglas avanzadas. El objetivo es construir una infraestructura que ofrezca aislamiento de tráfico, gestión centralizada y capacidad de escalar a laboratorios de seguridad o SD‑WAN, todo dentro de un chasis de mini PC.

Causa

  1. Hardware de nivel consumidor – routers Wi‑Fi típicos solo manejan NAT básico y carecen de puertos trunk.
  2. Falta de virtualización – sin una capa como Proxmox, cada servicio (firewall, DHCP, IDS) corre en hardware dedicado, lo que duplica costos.
  3. Configuración de VLAN incompleta – muchos usuarios crean VLANs solo en el switch, pero el router sigue operando en modo “access”, impidiendo el aislamiento real.
  4. APs sin mapping SSID‑VLAN – los puntos de acceso gestionados (Aruba, Cisco, Ubiquiti) pueden etiquetar tráfico, pero si el controlador no está conectado a un trunk, el tráfico vuelve a mezclarse.

Estos factores combinados provocan que la red doméstica se comporte como una única LAN, con riesgos de seguridad y saturación del enlace de 100 Mbps.

Solución

Una arquitectura basada en un mini PC (Intel NUC, AMD Ryzen Embedded o equivalente) con Proxmox VE como hipervisor permite consolidar varios servicios críticos:

  1. Instalar Proxmox en el mini PC y habilitar IOMMU para pasar NICs dedicadas a VMs.
  2. Crear dos NICs físicas: una conectada al ISP (WAN) y otra al switch gestionado (LAN). La NIC LAN debe soportar 802.1Q y, de ser posible, ser una tarjeta Intel o Broadcom con driver nativo.
  3. Configurar un bridge VLAN en Proxmox (vmbr0) que actúe como trunk. Cada VLAN se define como sub‑interface (vmbr0.10, vmbr0.20, etc.).
  4. Desplegar una VM de OPNsense y asignarle las interfaces:
    • em0 → WAN (sin tagging).
    • em1 → trunk (vmbr0) con todas las VLANs necesarias.
  5. Dentro de OPNsense, crear interfaces virtuales para cada VLAN (10 Users, 20 Servers, 30 IoT, 40 Cameras). Activar inter‑VLAN routing y aplicar reglas de firewall por zona.
  6. Integrar los Aruba APs: en el controlador Aruba Central o en el UI local, mapear cada SSID a la VLAN correspondiente (ej. “Home‑Users” → VLAN 10). Conecta los APs al mismo puerto trunk del switch.
  7. DHCP: delegar la asignación a OPNsense por VLAN, evitando colisiones.
  8. Monitorización: instalar LibreNMS o Zabbix en una VM adicional, apuntando a los interfaces de OPNsense y a los puertos del switch para obtener métricas de ancho de banda y alertas.

Esta solución mantiene la carga de procesamiento en el mini PC (CPU ≥ 4 cores, 8 GB RAM) y permite añadir más VMs (IDS/IPS, SIEM) sin cambiar el hardware.

Alternativas prácticas

  • pfSense en lugar de OPNsense si se prefiere una base BSD.
  • Docker Compose para servicios ligeros (AdGuard Home, Pi-hole) en vez de VMs, siempre que la NIC trunk esté expuesta al contenedor.
  • Switch de capa 2 gestionado con 24 puertos si la cantidad de dispositivos crece; el mini PC sigue siendo el router y controlador de políticas.

Cuándo aplicar esta solución

  • Síntomas: velocidad limitada a 100 Mbps, dispositivos en diferentes VLANs pueden comunicarse sin restricción, o el router se reinicia bajo carga.
  • Entorno: hogar o pequeña oficina con 1‑2 Gbps de fibra, necesidad de segmentación (IoT, invitados, servidores) y deseo de experimentar con firewall avanzado o SD‑WAN.
  • No aplica: escenarios donde la latencia de la virtualización es inaceptable (ej. gaming de alta frecuencia) o donde el ISP impone NAT obligatorio sin opción de modo puente.

Código

# Proxmox: crear bridge VLAN
cat > /etc/network/interfaces <<EOF
auto lo
iface lo inet loopback

auto enp1s0
iface enp1s0 inet manual

auto enp2s0
iface enp2s0 inet manual

auto vmbr0
iface vmbr0 inet static
    address 192.168.1.1/24
    bridge_ports enp2s0
    bridge_stp off
    bridge_fd 0

# VLAN sub‑interfaces
auto vmbr0.10
iface vmbr0.10 inet manual
    vlan-raw-device vmbr0

auto vmbr0.20
iface vmbr0.20 inet manual
    vlan-raw-device vmbr0

auto vmbr0.30
iface vmbr0.30 inet manual
    vlan-raw-device vmbr0
EOF

systemctl restart networking

# OPNsense: crear VLAN en la CLI (opnsense-shell)
opnsense-shell -c "ifconfig em1 create vlan 10 vlandev em1"
opnsense-shell -c "ifconfig em1 create vlan 20 vlandev em1"
opnsense-shell -c "ifconfig em1 create vlan 30 vlandev em1"

Verificación

  1. Desde una máquina en VLAN 10, ejecutar ping 192.168.10.1 (IP del OPNsense en esa VLAN).
  2. Probar acceso a internet; el tráfico debe pasar por la interfaz WAN de OPNsense.
  3. Conectar un cliente al SSID “Home‑IoT” y confirmar que recibe una IP del rango 192.168.30.0/24.
  4. En LibreNMS, verificar que los puertos del switch muestran etiquetas VLAN y que el tráfico está aislado entre VLAN 10 y VLAN 20.
  5. Revisar los logs de OPNsense para asegurarse de que las reglas de firewall están aplicando los permit/deny esperados.

Notas adicionales

  • NICs dual‑port con soporte de offload reducen la carga de CPU en el mini PC; evita adaptadores USB‑Ethernet para trunk.
  • MTU: si se habilita VPN o IPSec, ajusta la MTU a 1400 bytes en los interfaces VLAN para evitar fragmentación.
  • Respaldo de configuración: exporta la configuración de OPNsense (/conf/config.xml) y de Proxmox (/etc/pve/datacenter.cfg) antes de cambios mayores.
  • Actualizaciones: mantén el firmware del switch Aruba actualizado; versiones antiguas pueden perder el mapping SSID‑VLAN bajo alta carga.
  • Escalabilidad: cuando el número de dispositivos supere 50 por VLAN, considera agregar un segundo mini PC en HA activo‑pasivo y sincronizar la configuración de OPNsense mediante CARP.