Cómo diseñar y escalar un homelab multi‑WAN con OPNsense y Proxmox

Problema

Los entusiastas de homelab suelen iniciar con una única conexión a Internet y un servidor pequeño. Cuando añaden una segunda línea de fibra, múltiples VLAN, servicios de seguridad, monitorización y contenedores, el consumo de CPU, RAM y ancho de banda crece rápidamente. El patrón que se repite es: sobre‑dimensionar la arquitectura sin una planificación de recursos ni una estrategia de escalado, lo que genera:

• Saturación de la CPU en el nodo que ejecuta OPNsense y Proxmox simultáneamente.
• Contención de memoria cuando varios LXC (ntopng, Immich, Paperless, etc.) compiten por los 16 GB disponibles.
• Ruido y calor excesivo en hardware antiguo, obligando a mover equipos a ubicaciones no ideales.
• Complejidad de red (dos WAN, VLANs, DNS‑over‑TLS, NTPsec) que se vuelve difícil de depurar sin una base estructurada.

El objetivo de la guía es proporcionar un marco reutilizable para planificar, implementar y escalar un homelab multi‑WAN sin caer en los cuellos de botella típicos.

Causa

1. Consolidación de funciones en un único nodo
   Ejecutar OPNsense, Proxmox y varios contenedores en una mini‑PC N100 (16 GB RAM) obliga a que el hipervisor comparta recursos críticos con el firewall. Cada paquete que atraviesa OPNsense pasa por la capa de virtualización, añadiendo latencia y carga de CPU.

2. Falta de separación de tráfico
   Cuando todas las VLAN y servicios DNS/NTP comparten la misma interfaz física, los paquetes de gestión compiten con el tráfico de datos, provocando pérdida de paquetes y aumentos de RTT.

3. Escalado ad‑hoc de hardware
   Añadir un segundo nodo sin una arquitectura de clúster (por ejemplo, Ceph o Proxmox HA) solo desplaza la carga, pero no la distribuye de forma inteligente. Además, la ausencia de balanceo de carga entre los dos WAN deja un enlace subutilizado.

4. Gestión de certificados y DNS personalizada sin automatización
   Un CA propio (step‑ca) y resolvers personalizados (AdGuard → dnsmasq → DoT) son potentes, pero su configuración manual se vuelve frágil al crecer el número de contenedores.

Solución

1. Separar funciones en nodos dedicados

Con esta separación, el firewall no compite por CPU con los contenedores y el hipervisor tiene suficiente memoria para alojar VMs y LXC.

2. Arquitectura de red basada en trunk y tagged VLANs

1. Crear un trunk entre el firewall y el switch de 10 Gbps.
2. Asignar VLAN IDs:
   • VLAN 10 – LAN interna
   • VLAN 20 – DMZ (Immich, Paperless)
   • VLAN 30 – IoT / Tor gateway
   • VLAN 40 – Management (Proxmox, DNS, NTP)
3. En OPNsense, habilitar Interface → Assignments → VLAN y mapear cada VLAN a una interfaz virtual.
4. En Proxmox, usar Linux Bridge con vlan_aware = 1 y conectar cada VM/LXC a la bridge correspondiente.

Esto garantiza que el tráfico de gestión nunca se mezcle con el de los servicios de usuario y permite aplicar políticas de firewall por VLAN.

3. Balanceo de carga multi‑WAN con policy‑based routing

OPNsense permite crear Gateways para cada enlace de fibra y definir Rules que dirijan tráfico según origen/destino o tipo de servicio. Un ejemplo típico:

• Todo el tráfico de VLAN 10 (LAN) usa el enlace más barato (WAN‑A).
• Tráfico de VPN y Tor (VLAN 30) se enruta siempre por WAN‑B para aislarlo.
• Servicios críticos (NTP, DNS) se balancean usando Round‑Robin.

4. Automatizar certificados y DNS

• step‑ca → generar certificados automáticamente con renewal hooks que actualicen los contenedores.
• AdGuard Home → usar custom upstream apuntando a 127.0.0.1#5353 donde corre dnsmasq. Configurar dnsmasq para reenviar consultas DoT a Cloudflare (1.1.1.1#853).
• Guardar la configuración en un repositorio Git y usar Ansible o Terraform para aplicar cambios en todos los nodos.

5. Monitoreo y alertas centralizadas

Instalar Prometheus + Grafana en un contenedor dedicado. Exportar métricas de:

• OPNsense (via opnsense_exporter)
• Proxmox (pve_exporter)
• LXC (node_exporter + cgroup metrics)

Crear alertas para CPU > 80 % en OPNsense, uso de RAM > 75 % en contenedores, y temperatura > 70 °C en el nodo de hardware.

6. Escalado horizontal con Proxmox HA

Cuando el segundo nodo está listo, habilitar Cluster → HA Manager. Definir grupos de recursos (CPU, RAM) y mover VMs/LXC críticos a los nodos menos cargados. El shared storage (NFS o Ceph) permite migraciones en vivo sin downtime.

Cuándo aplicar esta solución

Se recomienda cuando:

• Se dispone de al menos dos enlaces de Internet y se desea balanceo o redundancia.
• El número de contenedores supera 5 o el consumo de RAM supera 12 GB en un solo nodo.
• Se necesita segmentación de red (VLAN) para separar servicios críticos de los de prueba.
• Aparecen síntomas de alta latencia, pérdida de paquetes o ruido excesivo del hardware.

No es necesario si:

• Solo se ejecuta una única VM o contenedor y la carga es mínima.
• El firewall está en modo router‑only sin funciones de inspección profunda.
• No se requiere alta disponibilidad ni balanceo de carga.

Código

# Crear VLAN 20 en OPNsense (CLI)
opnsense-shell
ifconfig em0.20 create vlan 20 vlandev em0
ifconfig em0.20 inet 192.168.20.1/24 up

# Configurar bridge en Proxmox con VLAN awareness
cat > /etc/pve/lxc/101.conf <<EOF
lxc.net.0.type = veth
lxc.net.0.link = vmbr0
lxc.net.0.flags = up
lxc.net.0.hwaddr = 00:16:3e:xx:xx:xx
lxc.net.0.vlan = 20
EOF
pct start 101

Verificación

1. Conectividad VLAN
   Desde una VM en VLAN 20, ejecutar ping 192.168.20.1. Debería responder sin pérdida.

2. Rutas multi‑WAN
   En OPNsense, abrir Diagnostics → Routes y confirmar que los gateways WAN‑A y WAN‑B aparecen con estado Online.

3. Balanceo de carga
   Ejecutar traceroute a un host externo y observar que el primer salto corresponde al WAN esperado según la regla de firewall.

4. Uso de recursos
   En Proxmox, usar pveperf y htop dentro de cada LXC para validar que CPU y RAM están por debajo del 70 % bajo carga típica.

5. Alertas
   Verificar en Grafana que los paneles de CPU y temperatura no disparan alarmas durante una prueba de estrés (stress-ng --cpu 4 --timeout 60s).

Notas adicionales

• Aislamiento acústico: montar los nodos en racks con paneles de espuma acústica reduce el ruido del desktop antiguo.
• Backup de configuración: exportar la configuración de OPNsense (/conf/backup/config.xml) y de Proxmox (pvebackup) a un NAS NFS para recuperación rápida.
• Actualizaciones coordinadas: usar Ansible para aplicar parches simultáneos a OPNsense, Proxmox y contenedores, evitando versiones desalineadas que puedan romper la cadena de DNS/DoT.
• Plan de expansión: antes de añadir más RAM, evalúa si el cuello de botella está en la red (NIC) o en el almacenamiento (IOPS). A veces una SSD NVMe adicional brinda mayor beneficio que 8 GB de RAM extra.