# Tutorial 6: Aislar IoT e invitados en SonicWall y UniFi - Link: https://www.clhome.net/aislar-iot-invitados-sonicwall-unifi/ - Published: 2026-10-14T11:21:22+02:00 - Author: gerard Ruta de aprendizaje / 6 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[7](https://www.clhome.net/permitir-impresion-chromecast-y-mdns-entre-vlans-de-forma-segura-3/) [8](https://www.clhome.net/diagnosticar-problemas-de-vlan-dhcp-y-conectividad/)[9](https://www.clhome.net/preparar-un-acceso-de-recuperacion-para-el-firewall/) [← Anterior](https://www.clhome.net/crear-reglas-de-firewall-entre-vlans-en-sonicwall/) [Índice de guías](https://www.clhome.net/guias/)[Siguiente →](https://www.clhome.net/permitir-impresion-chromecast-y-mdns-entre-vlans-de-forma-segura-3/) ![Infografía del tutorial 6 de CLHOME sobre aislamiento de IoT e invitados con SonicWall y UniFi, usando direcciones IP de ejemplo ficticias.](https://www.clhome.net/wp- content/uploads/2026/10/clhome-tutorial-6-infografia-interna-aislamiento-iot-invitados. png) Resumen visual del aislamiento: IoT e invitados conservan el acceso necesario a Internet, pero no pueden iniciar conexiones hacia redes privadas no autorizadas. Las direcciones son ejemplos ficticios. En los tutoriales anteriores hemos diseñado la red, creado las VLAN en SonicWall, preparado los puertos trunk/access de UniFi, asociado las redes Wi-Fi a sus VLAN y aprendido a crear reglas de firewall. En esta sexta entrega vamos a aplicar esos conceptos a un objetivo concreto: **aislar los dispositivos IoT y la red de invitados sin cortar los servicios que necesitan**. La guía utiliza nombres, VLAN ID y direcciones ficticias. Adáptalos a tu diseño y no copies reglas sin revisar las zonas, el orden y las políticas que ya existen en tu SonicWall. Haz los cambios de uno en uno, guarda una copia de seguridad y conserva una vía de recuperación local. ## Qué queremos conseguir * Permitir que los dispositivos IoT salgan a Internet cuando lo necesiten. * Evitar que IoT inicie conexiones no autorizadas hacia ordenadores, servidores y administración. * Permitir a los invitados navegar por Internet sin acceder a las redes privadas. * Mantener DHCP, DNS y otros servicios básicos que cada red necesite. * Comprobar el aislamiento con pruebas reales, no solo mirando que las reglas estén creadas. ## Antes de empezar: requisitos y seguridad Esta guía sirve para revisar y planificar el aislamiento. La configuración exacta depende de las zonas, interfaces y reglas que ya tengas creadas; por eso, no copies una regla de ejemplo sin contrastarla con tu instalación. * Ten acceso administrativo a SonicWall y UniFi, preferiblemente desde un equipo conectado a la red de administración. * Guarda una copia de seguridad de la configuración de SonicWall y anota qué reglas vas a revisar. * Ten a mano la tabla de VLAN, subred, zona y función que preparaste en el tutorial 1. * Haz los cambios cuando puedas probarlos desde un equipo conectado a cada red, y cambia una sola cosa cada vez. * No modifiques la interfaz de administración, la VLAN nativa ni las reglas que permiten tu acceso remoto mientras no tengas una vía local de recuperación. **Importante:** si no sabes identificar la zona de origen y la de destino, detente antes de guardar cambios. Consulta primero las interfaces en SonicOS o vuelve al [tutorial 2 sobre VLAN en SonicWall](https://www.clhome.net/configurar-vlans-sonicwall-tz670/). Es más seguro dejar una política pendiente que bloquear tu propio acceso al firewall. ## Paso 1. Repasa la topología antes de cambiar reglas El aislamiento solo funciona si el tráfico pasa por el equipo que aplica las políticas. En esta serie, UniFi gestiona los SSID y los puntos de acceso, mientras que SonicWall realiza el enrutamiento entre las redes que tiene conectadas y aplica las reglas correspondientes. En SonicOS, revisa **NETWORK → System → Interfaces** y confirma qué interfaz, subinterfaz y zona corresponden a cada VLAN. Después abre **POLICY → Rules and Policies → Access Rules**. Los nombres de menú pueden variar según la versión. Si dos redes pueden comunicarse a través de otro router, un switch de capa 3 o una ruta que evita el firewall, las reglas de SonicWall no controlarán necesariamente ese tráfico. Confirma primero que el camino real coincide con el diseño. ## Paso 2. Define redes de ejemplo | Red de ejemplo | VLAN ficticia | Uso | Política objetivo | | Hogar | 140 | Ordenadores y móviles personales | Acceso a Internet y a servicios autorizados | | IoT | 160 | Bombillas, enchufes y otros dispositivos conectados | Internet y servicios imprescindibles; sin acceso general a redes privadas | | Invitados | 190 | Dispositivos de visitas | Acceso a Internet; sin acceso a redes internas | | Administración | Ejemplo independiente | Gestión de la infraestructura | Solo dispositivos y servicios administrativos autorizados | Los números anteriores son ejemplos ilustrativos y no describen la red privada de CLHOME. Usa los identificadores y subredes que hayas documentado para tu instalación. Si todavía no tienes un inventario claro de VLAN, vuelve al [tutorial 1: diseño de la red](https://www.clhome.net/disenar-red-homelab-vlans-sonicwall-unifi/) antes de continuar. ## Paso 3. Identifica los servicios básicos Antes de bloquear comunicaciones, comprueba cómo reciben dirección IP los clientes y qué servidores DNS utilizan. DHCP y DNS son servicios distintos: un cliente puede conectarse al Wi-Fi y recibir una IP, pero no resolver nombres si la configuración DNS o las reglas necesarias son incorrectas. * **DHCP:** confirma qué equipo entrega las direcciones y que el ámbito corresponde a la VLAN correcta. * **DNS:** identifica el servidor que deben usar los clientes y comprueba si está en la propia VLAN o en otra red. * **Gateway:** comprueba que cada dispositivo utiliza la dirección del router de su subred. * **Hora y actualizaciones:** algunos dispositivos IoT necesitan NTP o acceso a servicios del fabricante para funcionar correctamente. No abras acceso general entre redes para resolver un problema de DNS o DHCP. Identifica el servicio, su destino y el protocolo necesario; en el siguiente tutorial de la serie veremos cómo tratar excepciones concretas para servicios domésticos. ## Paso 4. Diseña la política antes de aplicarla Es más fácil detectar errores si decides primero qué comunicaciones deben permitirse y cuáles deben bloquearse. Esta matriz expresa el objetivo de seguridad, no una lista de reglas que debas copiar literalmente: en SonicOS, la selección de zonas y la configuración existente determinan cómo se implementa. | Origen | Destino | Objetivo | | IoT | Internet | Permitir únicamente la salida necesaria para los dispositivos | | IoT | Hogar y Administración | Bloquear conexiones iniciadas por IoT, salvo excepciones justificadas | | Invitados | Internet | Permitir navegación y servicios básicos necesarios | | Invitados | Hogar, IoT y Administración | Bloquear el acceso a recursos privados | | Hogar | IoT | Permitir solo los dispositivos y servicios que realmente necesites controlar | | Administración | Equipos de infraestructura | Permitir gestión únicamente desde equipos autorizados | Ten en cuenta que los firewalls suelen mantener el estado de las conexiones: una respuesta a una conexión permitida no equivale a permitir que el dispositivo de destino inicie cualquier conexión nueva. Aun así, valida el comportamiento real con las reglas y opciones de tu versión. ## Paso 5. Revisa las reglas de IoT hacia redes privadas Ahora vamos a revisar la política desde IoT hacia las redes privadas. Los nombres exactos de los menús pueden variar según la versión de SonicOS, pero el objetivo es encontrar las reglas de acceso para la pareja de zonas correcta. 1. En SonicOS, abre **POLICY → Rules and Policies → Access Rules**. 2. Selecciona la vista o combinación de zonas que represente el tráfico que sale de IoT hacia Hogar. Si tu interfaz utiliza otro nombre de zona, confirma su correspondencia en **NETWORK → System → Interfaces**. 3. Revisa las reglas existentes de arriba abajo. Para cada una, comprueba el estado, la acción (Allow o Deny), el origen, el destino, los servicios y el orden. No cambies todavía ninguna regla que no entiendas. 4. Identifica si existe un permiso demasiado amplio que permita a toda la red IoT acceder a toda la red Hogar. Anota primero la regla y qué comunicaciones legítimas podrían depender de ella. 5. Si tu diseño requiere bloquear ese tráfico, crea o ajusta una regla de denegación limitada a la zona y al destino correctos. Usa el servicio adecuado para el alcance que quieras bloquear y colócala de forma que no quede anulada por una regla anterior más permisiva. 6. No elimines reglas generales ni cambies su orden sin entender sus efectos. Si no puedes determinar con seguridad qué regla debe tener prioridad, no guardes el cambio: consulta la documentación de tu versión o prueba primero en un entorno de laboratorio. 7. Guarda solo cuando hayas revisado todos los campos y realiza una prueba desde un dispositivo IoT antes de tocar otra regla. Una regla no se aplica a toda la red por el simple hecho de llamarse “Deny IoT”: solo afecta al tráfico que coincide con sus zonas, origen, destino y servicios. En un firewall con estado, las respuestas a conexiones permitidas pueden seguir funcionando; el objetivo aquí es impedir nuevas conexiones no autorizadas desde IoT hacia redes privadas. ## Paso 6. Revisa las reglas de invitados La red de invitados debe poder navegar, pero no acceder a la administración del firewall, al controlador UniFi, a servidores, ordenadores personales ni a dispositivos IoT privados. 1. En **Access Rules**, identifica la zona asociada a la VLAN de invitados y comprueba su subred en **NETWORK → System → Interfaces**. 2. Revisa las reglas desde esa zona hacia Hogar, IoT y Administración. Comprueba cada combinación de origen y destino por separado; no asumas que una regla cubre automáticamente todas las redes privadas. 3. Busca permisos que permitan a invitados acceder a redes internas sin una necesidad concreta. Anota su alcance antes de cambiarlos. 4. Aplica o ajusta las denegaciones necesarias para bloquear el acceso a redes privadas, sin bloquear por accidente los servicios básicos ni la salida a Internet. 5. Comprueba que los invitados siguen obteniendo IP y DNS y que pueden navegar. 6. Desde un dispositivo conectado al SSID de invitados, intenta acceder a un recurso interno de prueba que no esté autorizado. Debe fallar, mientras que la navegación a Internet debe seguir funcionando. El aislamiento de clientes Wi-Fi, cuando está disponible, puede impedir que los clientes de un mismo SSID se comuniquen directamente entre sí. No sustituye las reglas del firewall entre VLAN: son controles distintos y conviene comprobar ambos. ## Paso 7. Mantén el control desde la red de administración La red de administración es especialmente sensible porque permite gestionar el firewall, los switches, los puntos de acceso y otros servicios. Evita que IoT e invitados puedan iniciar conexiones hacia sus interfaces administrativas. * Permite el acceso administrativo solo desde equipos y redes autorizados. * No uses la red de invitados para administrar infraestructura. * No cambies la VLAN nativa ni la interfaz de administración como parte de esta prueba. * Antes de aplicar cambios, asegúrate de tener una vía local de recuperación que no dependa de la regla que vas a modificar. ## Paso 8. Valida el aislamiento con pruebas reales Realiza las pruebas con un dispositivo conectado a cada SSID. Una regla guardada no demuestra por sí sola que la política funciona: el tráfico puede utilizar otra ruta, coincidir con una regla diferente o depender de un servicio que no se ha tenido en cuenta. ![Infografía ilustrativa de una prueba ping sin respuesta hacia una dirección de ejemplo de la red privada, mientras IoT e invitados mantienen acceso a Internet.]( https://www.clhome.net/wp-content/uploads/2026/10/clhome-tutorial-6-prueba-ping- bloqueado.png) Ejemplo ilustrativo de ping sin respuesta desde IoT o invitados hacia una IP privada ficticia. Un ping fallido no demuestra por sí solo que el firewall esté bloqueando el tráfico: el destino también puede ignorar ICMP. **Importante:** la dirección que aparece en la imagen es ficticia. Para verificar el aislamiento, combina esta prueba con el registro de la regla en SonicWall y una prueba de acceso a un servicio de prueba que debería estar bloqueado. No utilices como objetivo un equipo real sin autorización. | Prueba | Resultado esperado | Si falla | | Cliente IoT recibe una IP | IP de la subred IoT y gateway correcto | Revisar VLAN, puerto trunk y DHCP | | Cliente IoT resuelve nombres y accede a Internet | Funciona según la política definida | Revisar DNS, salida WAN y registros | | IoT inicia una conexión a un equipo privado no autorizado | Bloqueado | Revisar zonas, reglas coincidentes y rutas | | Invitado navega por Internet | Funciona | Revisar DHCP, DNS y salida WAN | | Invitado intenta abrir un recurso privado | Bloqueado | Revisar permisos entre zonas y aislamiento | | Equipo administrativo autorizado accede al firewall | Funciona | Revisar que no se haya afectado la regla de gestión | Si algo no funciona, revisa primero la dirección IP, la máscara, el gateway y el DNS del cliente. Después comprueba la VLAN, la zona de origen y destino, el servicio y los registros de SonicOS. Haz un solo cambio controlado cada vez y repite la prueba. ## Errores frecuentes que debes evitar * Bloquear todo el tráfico de IoT sin comprobar si necesita DNS, NTP o servicios del fabricante. * Permitir todo el tráfico entre Hogar e IoT solo para que funcione una aplicación. * Confundir el aislamiento entre clientes Wi-Fi con el aislamiento entre VLAN. * Crear reglas usando nombres de zonas sin confirmar a qué interfaces corresponden. * Modificar varias reglas a la vez y perder la posibilidad de identificar qué cambio provocó el fallo. * Probar solo el acceso a Internet y olvidar las pruebas hacia recursos privados. ## Lista final de comprobación * Los identificadores y las zonas se han comprobado en SonicOS. * IoT conserva los servicios básicos y la salida a Internet que necesita. * Los invitados pueden navegar sin acceder a recursos privados. * Las conexiones nuevas desde IoT hacia redes internas están bloqueadas salvo excepciones justificadas. * La administración solo es accesible desde equipos autorizados. * Se han probado tanto los accesos permitidos como los bloqueados. * Los cambios están documentados y existe una vía de recuperación. ## Referencias oficiales * [SonicWall: documentación técnica oficial](https://www.sonicwall.com/support/technical-documentation/). * [Ubiquiti: diagnóstico de problemas de VLAN](https://help.ui.com/hc/en-us/articles/9592924981911-Virtual-Network-VLAN-Troubleshooting). * [Ubiquiti: VLAN en puertos trunk y access](https://help.ui.com/hc/en-us/articles/26136855808919-Switch-Port-VLAN-Assignment-Trunk-Access-Ports). **Conclusión:** el aislamiento no consiste en cortar todas las comunicaciones, sino en permitir lo necesario y bloquear el resto. Cuando IoT e invitados funcionan sin alcanzar recursos privados, la red tiene una base de seguridad más sólida. El siguiente tutorial profundizará en las excepciones para impresoras, dispositivos multimedia y descubrimiento de servicios. ## Siguiente tutorial: excepciones para impresoras, Chromecast y servicios locales En el tutorial 7 veremos cómo permitir servicios concretos entre VLAN sin eliminar el aislamiento, incluyendo las particularidades del descubrimiento local, multicast y mDNS. [Pasa al siguiente tutorial](https://www.clhome.net/permitir-impresion-chromecast-y-mdns-entre-vlans-de-forma-segura-3/)