# Tutorial 8: Diagnosticar problemas de VLAN, DHCP y conectividad - Link: https://www.clhome.net/diagnosticar-problemas-de-vlan-dhcp-y-conectividad/ - Published: 2026-10-12T13:15:48+02:00 - Author: gerard Ruta de aprendizaje / 8 de 9 [1](https://www.clhome.net/disenar-red-homelab-vlans-sonicwall-unifi/)[2](https://www.clhome.net/configurar-vlans-sonicwall-tz670/) [3](https://www.clhome.net/configurar-un-switch-unifi-con-vlans-y-puertos-trunk-access/) [4](https://www.clhome.net/configurar-redes-wi-fi-unifi-asociadas-a-vlans/)[5](https://www.clhome.net/crear-reglas-de-firewall-entre-vlans-en-sonicwall/) [6](https://www.clhome.net/aislar-iot-invitados-sonicwall-unifi/)[7](https://www.clhome.net/permitir-impresion-chromecast-y-mdns-entre-vlans-de-forma-segura-3/) 8[9](https://www.clhome.net/preparar-un-acceso-de-recuperacion-para-el-firewall/) [← Anterior](https://www.clhome.net/permitir-impresion-chromecast-y-mdns-entre-vlans-de-forma-segura-3/) [Índice de guías](https://www.clhome.net/guias/)[Siguiente →](https://www.clhome.net/preparar-un-acceso-de-recuperacion-para-el-firewall/) ![Infografía interna CLHOME para diagnosticar problemas de VLAN, DHCP, puertos UniFi, rutas y reglas SonicWall con valores de ejemplo ficticios.](https://www.clhome.net/ wp-content/uploads/2026/10/clhome-tutorial-8-infografia-interna-diagnostico-vlan- dhcp.png) Guía visual de diagnóstico: sigue el recorrido desde el cliente y el puerto de acceso hasta la VLAN, el gateway, el firewall y el servicio. Todos los valores son ejemplos ficticios. 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: ```wp-block-code ipconfig /all ping 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 ```wp-block-code ip addr ip route ping -c 4 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](https://www.sonicwall.com/support/technical-documentation/). * [Centro de ayuda oficial de Ubiquiti](https://help.ui.com/). * [Microsoft: comando ipconfig](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ipconfig). * [Microsoft: comando nslookup](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/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. [Pasa al siguiente tutorial](https://www.clhome.net/preparar-un-acceso-de-recuperacion-para-el-firewall/)