Tutorial 8: Diagnosticar problemas de VLAN, DHCP y conectividad

Cuando una red deja de funcionar, el error puede estar en varios puntos: el cliente, la conexión Wi-Fi, el puerto del switch, la VLAN, DHCP, la puerta de enlace, DNS, una ruta o una regla del firewall. La forma más rápida y segura de encontrarlo es comprobar cada tramo en orden, empezando por lo más cercano al dispositivo y avanzando hacia el destino.

Esta guía continúa la serie de CLHOME sobre SonicWall y UniFi. Utiliza nombres y direcciones de ejemplo ficticios; no copies valores sin adaptarlos a tu red. No desactives reglas de seguridad ni cambies varias cosas a la vez para “probar suerte”.

Qué necesitas antes de diagnosticar

• Un dispositivo afectado y, si es posible, otro que funcione correctamente para comparar.
• Acceso de lectura a UniFi Network y SonicOS.
• La subred, VLAN y puerta de enlace esperadas para el cliente, obtenidas de tu documentación privada.
• Una copia de seguridad actual de la configuración antes de realizar cambios.
• Un registro de qué falla, desde cuándo, en qué dispositivo y si afecta a una VLAN o a varias.

Si estás conectado remotamente a través del enlace o la VLAN que vas a modificar, no cambies el perfil del puerto ni la interfaz del firewall hasta disponer de un método de recuperación local. Primero diagnostica; después cambia una sola cosa y vuelve a probar.

Paso 1. Define el síntoma con precisión

“No funciona Internet” es demasiado general. Identifica cuál de estos escenarios se parece al problema real:

Síntoma	Primera hipótesis que comprobar
El cliente no tiene dirección IP o recibe una dirección automática no esperada	Wi-Fi/cable, VLAN del puerto, DHCP y alcance del servidor DHCP.
Tiene IP, pero no alcanza su puerta de enlace	Máscara, VLAN, etiquetado del puerto, gateway correcto y conectividad local.
Alcanza la puerta de enlace, pero no Internet	Ruta por defecto, NAT, política de salida, estado WAN y DNS.
Accede a Internet, pero no a un servicio interno autorizado	Reglas entre zonas, ruta de retorno, servicio/puerto y dirección de destino.
Una VLAN funciona y otra no	Comparar configuración de interfaz, DHCP, trunk, perfil del puerto y reglas.
Un dispositivo no aparece automáticamente, aunque funciona por IP	Descubrimiento del servicio, multicast/mDNS y no necesariamente el firewall general.

Paso 2. Comprueba el cliente

Empieza en el propio equipo. Confirma que está conectado al SSID o puerto previsto, que no está usando una VPN inesperada y que ha recibido una configuración IP coherente con la red asignada.

En Windows

Abre Símbolo del sistema y ejecuta:

ipconfig /all
ping <puerta_de_enlace_de_ejemplo>
nslookup example.com

Busca la dirección IPv4, la máscara, la puerta de enlace y los servidores DNS. Sustituye el texto entre los signos por el valor de tu documentación; no publiques aquí los datos reales.

En Linux o macOS

ip addr
ip route
ping -c 4 <puerta_de_enlace_de_ejemplo>
nslookup example.com

En macOS, si el comando ip no está disponible, consulta la configuración de red desde Ajustes del Sistema o utiliza ifconfig y route -n get default. Algunos sistemas bloquean ICMP, así que un ping fallido no demuestra por sí solo que el servicio o la red estén caídos.

Paso 3. Comprueba la VLAN y el puerto en UniFi

En UniFi Network, abre la vista de clientes y localiza el equipo afectado. Revisa a qué punto de acceso o puerto está conectado, qué red le corresponde y si la dirección IP coincide con el plan de direccionamiento.

1. Comprueba que el SSID está asociado a la red correcta, si el cliente usa Wi-Fi.
2. Si está cableado, revisa el perfil del puerto: un puerto de acceso normalmente asigna una red al cliente; un trunk transporta varias VLAN y suele usarse para enlaces a switches, firewall o puntos de acceso.
3. En el enlace entre switches, firewall y AP, confirma que las VLAN necesarias están permitidas y etiquetadas como corresponde.
4. Comprueba que la VLAN nativa/untagged coincide en ambos extremos cuando se utiliza. No cambies esta opción sin saber qué tráfico la utiliza.
5. Revisa si el cliente está aislado por una política de Wi-Fi o una función de aislamiento entre clientes.

Si solo falla un puerto, compara su configuración con otro puerto equivalente que funcione. No copies un perfil trunk a un equipo final sin comprobarlo: podrías exponer varias VLAN al dispositivo o dejarlo sin conectividad.

Paso 4. Verifica interfaces y DHCP en SonicWall

En SonicOS, revisa las interfaces y subinterfaces VLAN. Confirma que la interfaz correspondiente está habilitada, pertenece a la zona esperada y utiliza la dirección de gateway documentada. No cambies la interfaz WAN ni la interfaz de administración como parte de una prueba genérica.

Después abre la sección DHCP Server (la ruta exacta puede variar según la versión). Para la red afectada, verifica:

• Que el ámbito DHCP esté habilitado y asociado a la interfaz correcta.
• Que el rango de direcciones pertenezca a la subred esperada y no incluya direcciones reservadas o estáticas.
• Que la máscara, el gateway y los DNS entregados sean correctos.
• Que exista espacio disponible en el rango y no haya conflictos de direcciones.
• Que las solicitudes DHCP puedan atravesar el camino de capa 2 hasta el servidor o relay configurado.

Si el gateway responde pero el cliente no recibe una dirección, centra la investigación en DHCP, la VLAN y el camino entre el cliente y el servidor. Si el cliente recibe una dirección de otra subred, revisa especialmente la VLAN asignada al puerto/SSID y si existe otro servidor DHCP no previsto.

Paso 5. Comprueba ruta, NAT, DNS y reglas de acceso

Una vez confirmados el cliente, la VLAN y DHCP, avanza hacia el firewall. Haz las pruebas por capas: primero gateway, después una IP externa conocida y finalmente un nombre DNS. Utiliza destinos de prueba autorizados y no interpretes un único resultado como prueba definitiva.

Prueba	Qué puede indicar	Siguiente revisión
El cliente no alcanza el gateway	Problema local, VLAN, etiquetado, dirección o interfaz	UniFi, subinterfaz y configuración IP
Gateway accesible, IP externa no accesible	Ruta, NAT, política de salida, WAN o filtrado del destino	Routing, NAT, Access Rules y estado WAN
IP externa accesible, nombre DNS no resuelve	Problema de DNS o de acceso al servidor DNS	DNS recibido por DHCP, servidor y reglas necesarias
Internet funciona, pero falla una red privada	Regla inter-VLAN, ruta de retorno, servicio o aislamiento previsto	Reglas de acceso, objetos y logs
La conexión se inicia pero la aplicación falla	Puerto/protocolo adicional, resolución de nombres o requisito de la app	Documentación del servicio y registros

En las reglas de SonicWall revisa las zonas de origen y destino, los objetos de dirección, los servicios, la acción y el orden de evaluación. Consulta también los registros para localizar una denegación coincidente con la prueba. No desactives el firewall ni añadas una regla “Any to Any” para comprobar si así funciona.

Paso 6. Utiliza los registros para localizar el punto de fallo

Reproduce el fallo una sola vez y anota la hora. Después revisa los registros de SonicWall y los eventos de UniFi en ese intervalo. Busca la IP de origen y destino de ejemplo que hayas usado en la prueba, la acción aplicada y el motivo del evento. En capturas destinadas a publicar, sustituye los valores reales por ejemplos ficticios.

• Una denegación de firewall apunta a revisar la política coincidente, no a permitir todo el tráfico.
• La ausencia de un registro no demuestra que el tráfico haya pasado: puede no generarse el evento esperado o estar en otra vista.
• Una desconexión de cliente o cambio de AP puede orientar hacia Wi-Fi, señal o roaming.
• Una asignación DHCP inesperada puede revelar un ámbito incorrecto, una VLAN mal asignada o un servidor DHCP no previsto.
• Los errores de enlace, negociación o STP pueden apuntar a un puerto, cable o topología, no a una regla IP.

Paso 7. Aplica una corrección controlada

Cuando tengas una hipótesis respaldada por las pruebas, cambia solo el ajuste relacionado con ella. Guarda el estado original, realiza el cambio en una ventana adecuada y repite exactamente las mismas pruebas.

1. Escribe qué síntoma quieres corregir y qué evidencia apunta a la causa.
2. Haz una copia de seguridad o registra el valor original.
3. Modifica un único ajuste: VLAN/puerto, ámbito DHCP, ruta, servicio o regla concreta.
4. Repite la prueba desde el mismo cliente y destino.
5. Comprueba también que las redes que deben seguir aisladas continúan bloqueadas.
6. Si empeora o pierdes acceso, revierte el cambio por el método de recuperación preparado.
7. Documenta el resultado para evitar repetir diagnósticos en el futuro.

Casos frecuentes y orientación rápida

Situación	Revisión prioritaria
Todos los clientes de una VLAN fallan	Interfaz/subinterfaz, VLAN permitida en el trunk, gateway y DHCP.
Solo falla un cliente	SSID/puerto, configuración IP, reserva DHCP, cable, señal o firewall local.
Funciona por cable pero no por Wi-Fi	SSID, VLAN asociada, grupo de AP, aislamiento Wi-Fi y perfil de radio.
Funciona una aplicación, pero no otra	DNS, puertos, protocolo, proxy/VPN y requisitos específicos de la aplicación.
La conectividad se pierde tras cambiar un trunk	VLAN nativa, VLAN etiquetadas permitidas y coherencia de ambos extremos.
Internet funciona pero no se descubren dispositivos	Protocolo de descubrimiento, mDNS/multicast y aislamiento; no abrir todas las reglas.

Lista final de comprobación

• El síntoma se ha descrito y reproducido de forma controlada.
• El cliente tiene IP, máscara, gateway y DNS coherentes con su VLAN.
• El SSID o puerto asigna la red correcta y el trunk transporta solo las VLAN necesarias.
• La interfaz y el ámbito DHCP de SonicWall están activos y tienen valores correctos.
• Se han probado por separado gateway, conectividad externa, DNS y servicio final.
• Las reglas y registros se han revisado antes de cambiar permisos.
• Se ha realizado un solo cambio cada vez y se ha probado el resultado.
• El aislamiento de IoT e invitados sigue funcionando y la configuración está documentada.

Documentación y herramientas

• Documentación técnica oficial de SonicWall.
• Centro de ayuda oficial de Ubiquiti.
• Microsoft: comando ipconfig.
• Microsoft: comando nslookup.

Conclusión: diagnostica de cerca a lejos: cliente, Wi-Fi/cable, VLAN, DHCP, gateway, rutas/NAT, DNS y aplicación. Las pruebas ordenadas y los registros permiten aislar la causa sin abrir permisos innecesarios ni poner en riesgo el acceso a la infraestructura.

Siguiente tutorial: preparar un acceso de recuperación para el firewall

En el tutorial 9 prepararemos un método de recuperación documentado para no quedarnos sin acceso administrativo cuando un cambio de VLAN, trunk o firewall interrumpa la conectividad habitual.