Problema

En muchos homelabs se implementan varias VLAN para aislar servicios críticos (DMZ, gestión, IoT, invitados, etc.). Cuando la tabla de PVID (Port VLAN ID) no está alineada con la lógica de firewall, aparecen síntomas como:

  • Caídas intermitentes de SSID o rendimiento Wi‑Fi por debajo de 500 Mbps.
  • Latencia alta y pérdida de paquetes en enlaces Ethernet que deberían estar por encima de 850 Mbps.
  • Regla de firewall que “no debería” bloquear tráfico, pero lo hace, provocando que una VLAN no pueda comunicarse con otra ni con el router.
  • Reinicios de contenedores o VMs que dependen de DNS/Internet cuando el tráfico se filtra por una VLAN equivocada.

El patrón es claro: la segmentación está bien diseñada, pero la asignación de PVID a puertos físicos o a enlaces troncales está mal configurada, lo que genera “storm” de tráfico no etiquetado o etiquetado incorrectamente.

Causa

  1. PVID inconsistente entre switches
    Cada puerto de acceso necesita un PVID que coincida con la VLAN que debe aceptar sin etiqueta. Si el switch de borde (Netgear) tiene un PVID diferente al del controlador Omada, los frames sin etiqueta se asignan a la VLAN equivocada y el firewall inter‑VLAN los bloquea.

  2. Troncales mal configuradas
    En un trunk, el “native VLAN” (PVID del trunk) debe ser la misma en ambos extremos. Un desajuste hace que el tráfico sin etiqueta sea enviado a una VLAN que no tiene reglas de firewall, provocando pérdida de conectividad.

  3. Etiquetado doble
    Algunos AP Wi‑Fi crean VLANs por SSID y añaden etiquetas en el propio frame. Si el puerto del AP ya tiene un PVID, el frame termina con dos etiquetas (QinQ) que la mayoría de firewalls no interpretan, generando drops.

  4. Reglas de firewall basadas en VLAN IDs erróneas
    Cuando la tabla de PVID cambia, las reglas que referencian “VLAN 10 → VLAN 20” siguen apuntando a los IDs originales, dejando la nueva VLAN sin política y, por defecto, bloqueada.

  5. MTU y fragmentación
    Un PVID mal asignado puede forzar a los dispositivos a usar un MTU diferente al configurado en la red, provocando retransmisiones y caída de rendimiento, especialmente en Wi‑Fi 7.

Solución

Paso 1 – Auditoría de PVID y VLAN en todos los switches

  1. Exporta la tabla de VLAN y PVID de cada switch. En Omada se hace desde la GUI > Switch > VLAN > Export. En Netgear, usa show vlan o show running-config vía CLI.
  2. Crea una matriz con puertos → PVID → VLAN asignada. Busca discrepancias entre switches que conectan el mismo segmento.

Paso 2 – Unificar el “native VLAN” en los troncales

  • En Omada, edita el puerto trunk y fija “Native VLAN ID” al mismo número que en Netgear.
  • En Netgear, ejecuta (ejemplo para un puerto 1/0/1):
configure terminal
interface ethernet 1/0/1
switchport mode trunk
switchport trunk native vlan 10
exit

Asegúrate de que ambos extremos tengan el mismo ID.

Paso 3 – Corregir PVID de puertos de acceso

Para cada puerto que conecta un host o AP, asigna el PVID que corresponda a la VLAN esperada. En Omada:

configure terminal
interface gigabit-ethernet 1/0/5
switchport mode access
switchport access vlan 30   # VLAN de invitados
exit

En Netgear, usa switchport access vlan <id>.

Paso 4 – Revisar reglas de firewall inter‑VLAN

  • Exporta la lista de reglas. Busca referencias a IDs que ya no existen.
  • Actualiza las reglas para usar los nuevos IDs o, mejor, usa nombres de zona (DMZ, LAN, IOT) si el firewall lo permite.
  • Aplica política “allow established/related” antes de bloquear todo lo demás para evitar cortes inesperados.

Paso 5 – Verificar MTU y QoS

  • Configura MTU uniforme (1500 bytes) en todos los puertos de acceso y trunk.
  • Si usas Wi‑Fi 7, habilita “Jumbo Frames” solo en enlaces de back‑haul que lo soporten; de lo contrario, desactívalos.

Paso 6 – Test de conectividad por VLAN

  1. Desde un host en cada VLAN, ejecuta ping -I <interface> <gateway> para confirmar que el tráfico sale sin etiquetar.
  2. Usa traceroute -i <interface> <destino> para validar que el firewall permite el paso.

Paso 7 – Monitoreo continuo

Integra los eventos de cambio de VLAN en tu SIEM (Wazuh) para que cualquier modificación de PVID genere una alerta. Así evitarás que un error de configuración vuelva a pasar sin ser detectado.

Cuándo aplicar esta solución

  • Síntomas de rendimiento bajo en Ethernet o Wi‑Fi sin cambios recientes de hardware.
  • Reglas de firewall que parecen no aplicarse a una VLAN específica.
  • Caídas intermitentes de SSID que coinciden con cambios en la topología de switches.
  • Errores de “VLAN not found” en los logs del controlador Omada o del firewall.

No es necesario aplicar este proceso si:

  • La red es plana (una sola VLAN) y no se usan troncales.
  • No hay controladores de VLAN externos (solo DHCP sin segmentación).

Código

# Ejemplo de exportación y comparación rápida en Linux
ssh admin@omada "show vlan" > omada_vlan.txt
ssh admin@netgear "show vlan" > netgear_vlan.txt
diff -u omada_vlan.txt netgear_vlan.txt | grep "^[-+]"

# Aplicar PVID a varios puertos en Netgear con un bucle (bash)
for port in 1/0/5 1/0/6 1/0/7; do
  ssh admin@netgear "configure terminal; interface ethernet $port; switchport mode access; switchport access vlan 30; exit"
done

Verificación

  1. Ping de puerta de enlace desde cada VLAN → latencia < 5 ms, sin pérdida.
  2. Velocidad de transferencia con iperf3 -c <peer> en ambos sentidos; resultados > 800 Mbps en Ethernet, > 500 Mbps en Wi‑Fi.
  3. Revisión de logs en Omada y en el firewall: ausencia de “VLAN mismatch” o “PVID error”.
  4. Alertas de Wazuh: ninguna alerta de “network configuration change” después de la corrección.

Notas adicionales

  • Cuando uses varios SSID con VLAN diferentes, configura el AP para que el puerto al que está conectado sea trunk y deja que el AP etiquete los frames. No asignar PVID al puerto del AP evita el doble etiquetado.
  • Si el controlador Omada no permite editar el native VLAN, crea una VLAN “untagged” dedicada y úsala como puente entre switches.
  • Mantén una copia de la configuración de cada switch en un repositorio Git; así cualquier cambio accidental se revierte con git checkout.
  • En entornos con CGNAT (Cloudflare Tunnel), verifica que el túnel no esté forzando tráfico a una VLAN específica; de lo contrario, el firewall inter‑VLAN bloqueará la conexión.