Problema

En muchos entornos domésticos el router suministrado por el ISP no permite configuraciones avanzadas como VLANs, QoS o firewall granular. Cuando el objetivo es crear una red segmentada —por ejemplo, separar servidores de virtualización, dispositivos IoT y tráfico de invitados— el router del ISP se vuelve un cuello de botella. La solución típica es colocar un router VLAN‑aware detrás del equipo del ISP y delegar toda la lógica de red a este segundo dispositivo. Sin embargo, sin acceso directo al WAN del ISP, la única forma de exponer el router VLAN‑aware al exterior es mediante la función DMZ del router del ISP. El reto consiste en saber si esta arquitectura es viable, qué limitaciones tiene y cómo mitigar los riesgos de seguridad y de rendimiento.

Causa

Los problemas aparecen por tres motivos recurrentes:

  1. Falta de VLAN en el router del ISP – El equipo del proveedor solo gestiona una única subred LAN y no permite etiquetar tráfico. Cualquier intento de crear VLANs dentro de esa LAN termina en colisión de direcciones o en pérdida de conectividad.

  2. Restricciones de gestión del ISP – En muchos planes familiares el router está bloqueado (no se pueden cambiar DNS, desactivar DHCP, etc.). Reemplazarlo no es una opción, por lo que el usuario debe trabajar con el hardware existente.

  3. Necesidad de exponer servicios al exterior – Servidores de juegos, VPN, Jellyfin, etc., requieren una IP pública o al menos un puerto encaminado. Sin NAT doble o sin una zona DMZ, el tráfico externo nunca llega al router VLAN‑aware.

Estos factores hacen que la única vía práctica sea colocar el router VLAN‑aware en la DMZ del ISP, de modo que reciba la IP pública (o la IP del rango del ISP) y actúe como gateway para toda la red interna.

Solución

1. Preparar el router del ISP

  • Accede a la interfaz de gestión del ISP.
  • Busca la opción DMZ o DMZ Host. Normalmente se encuentra bajo “NAT”, “Port Forwarding” o “Advanced”.
  • Asigna la dirección MAC o la IP estática del router VLAN‑aware como host DMZ. El ISP enviará todo el tráfico entrante (excepto la propia gestión del ISP) a esa dirección.
  • Desactiva cualquier regla de port‑forwarding que apunte a dispositivos internos, ya que ahora el router VLAN‑aware será el único punto de entrada.

2. Configurar el router VLAN‑aware

a) WAN

  • Configura la interfaz WAN para obtener su dirección mediante DHCP del ISP o asigna la IP estática que el ISP haya reservado para ti.
  • Verifica que la puerta de enlace y los DNS sean los del ISP.

b) LAN y VLANs

  • Define las VLANs que necesites (ej. VLAN 10 para servidores, VLAN 20 para IoT, VLAN 30 para invitados).
  • Asocia cada puerto del switch gestionado a la VLAN correspondiente o usa trunking si el switch soporta 802.1Q.
  • Configura DHCP por VLAN o usa un servidor DHCP central (p. ej. en el router o en un contenedor Docker) que sirva rangos diferentes.

c) Firewall y NAT

  • En el router VLAN‑aware habilita NAT (masquerade) solo en la interfaz WAN.
  • Crea reglas de firewall que permitan tráfico entre VLANs solo cuando sea necesario (por ejemplo, permitir que la VLAN de servidores acceda a la VLAN de gestión pero bloquear el acceso inverso).
  • Si necesitas exponer puertos específicos al exterior (Jellyfin, WireGuard, etc.), crea reglas de port‑forwarding en este router, no en el ISP.

d) Doble NAT y consideraciones de rendimiento

  • La arquitectura genera doble NAT (ISP → router VLAN‑aware). La mayoría de los servicios funciona sin problemas, pero algunos juegos o VPN pueden requerir NAT traversal (UPnP o NAT‑PMP) o la configuración de DMZ adicional en el router VLAN‑aware para el dispositivo interno.
  • Monitorea la carga de CPU del router VLAN‑aware; si el tráfico supera sus capacidades, considera un hardware con mayor potencia o una solución basada en firewall dedicado (pfSense, OPNsense).

3. Integrar el switch gestionado

  • Conecta el puerto uplink del switch al puerto LAN del router VLAN‑aware configurado como trunk (etiquetado 1‑4094).
  • Asigna VLANs a los puertos según la topología deseada.
  • Verifica que los dispositivos conectados a puertos access reciban la VLAN correcta y que los servidores virtualizados (Proxmox) tengan interfaces VLAN en sus NICs.

4. Seguridad adicional

  • Desactiva la gestión remota del router del ISP (si es posible) o cambia su puerto de administración a una VLAN interna que nunca salga de la DMZ.
  • Actualiza firmware de ambos routers y del switch gestionado antes de la puesta en producción.
  • Habilita logging en el router VLAN‑aware para detectar intentos de escaneo o tráfico sospechoso entre VLANs.
  • Implementa un IDS/IPS ligero (Suricata, Snort) en una VM o contenedor para inspeccionar el tráfico que atraviesa la DMZ.

Cuándo aplicar esta solución

  • ISP no permite VLAN y no puedes reemplazar el equipo (plan familiar, contrato, etc.).
  • Necesitas segmentación de red para servidores, IoT y dispositivos de invitados.
  • Requieres exponer servicios al exterior (VPN, servidores de juego, media) y prefieres que el router VLAN‑aware sea el punto único de control.
  • El hardware del ISP tiene recursos limitados (p.ej., sin firewall avanzado) y deseas una capa de seguridad adicional.
  • No es crítico eliminar completamente el doble NAT (por ejemplo, en entornos de producción empresarial donde se exige una única traducción de NAT).

Escenarios donde NO aplicar

  • El ISP permite modo bridge o entrega una IP pública directa; en ese caso es mejor colocar el router VLAN‑aware como gateway sin DMZ.
  • El router VLAN‑aware no soporta NAT o firewall (solo conmutador capa 2); la DMZ no aportará seguridad.
  • Necesitas latencia mínima para aplicaciones sensibles (p. ej., trading en tiempo real) y el doble NAT introduce un retardo inaceptable.

Código

# Ejemplo de regla iptables en el router VLAN‑aware para permitir solo tráfico HTTP/HTTPS desde la VLAN 30 (invitados) hacia Internet
iptables -A FORWARD -i vlan30 -o eth0 -p tcp -m multiport --dports 80,443 -j ACCEPT
iptables -A FORWARD -i vlan30 -o eth0 -j DROP

Verificación

  1. Conectividad WAN – Desde una máquina en cualquier VLAN, ejecuta curl ifconfig.me. La IP mostrada debe coincidir con la asignada por el ISP (no la del router del ISP).
  2. Aislamiento de VLAN – Desde una PC en VLAN 20 (IoT), intenta ping a una IP en VLAN 10 (servidores). Debería fallar a menos que exista una regla explícita.
  3. Port‑forwarding – Accede a tu Jellyfin desde la red externa usando la IP pública y el puerto configurado. Verifica que la conexión atraviesa el router VLAN‑aware y no el ISP.
  4. Registro de firewall – Revisa los logs del router VLAN‑aware (/var/log/iptables.log o la GUI) para confirmar que los paquetes no deseados son bloqueados.
  5. Doble NAT – Usa una herramienta como traceroute hacia una dirección externa y observa dos saltos de NAT (ISP → router VLAN‑aware).

Notas adicionales

  • DHCP relay: si prefieres que el servidor DHCP centralizado (p. ej., en una VM) sirva a todas las VLANs, habilita DHCP relay en el router VLAN‑aware y apunta a la IP del servidor.
  • MTU: el salto adicional de NAT puede reducir la MTU efectiva. Configura una MTU de 1500 – 20 = 1480 en la WAN del router VLAN‑aware o habilita Path MTU Discovery.
  • Backup de configuración: exporta la configuración del router VLAN‑aware y del switch antes de cualquier cambio mayor; en caso de fallo, restaurar es mucho más rápido que reconstruir VLANs.
  • Monitorización: Grafana + Prometheus con exporters de SNMP para el router y el switch te ayudarán a detectar cuellos de botella antes de que impacten a los usuarios.
  • Future proof: si en el futuro el ISP permite bridge, simplemente cambia la DMZ a modo bridge y elimina la capa de NAT; la topología seguirá funcionando sin re‑diseñar VLANs.