Aislar los dispositivos IoT de tu red: qué funciona, qué se rompe y cuándo merece la pena

Casi todas las guías de seguridad doméstica repiten el mismo consejo: crea una red aparte para tus dispositivos inteligentes. Es un buen consejo. También es incompleto, porque rara vez explica qué deja de funcionar en cuanto lo aplicas.

Separar los dispositivos del resto de la red no es un interruptor de «más seguro». Es un intercambio. Se gana aislamiento frente a un dispositivo comprometido y se pierde, en distinta medida según cómo se haga, la capacidad de que el móvil y los aparatos se encuentren entre sí. Esta guía describe ese intercambio función por función y termina con un árbol de decisión para elegir sin ir probando a ciegas.

¿Qué significa realmente «aislar» un dispositivo?

Bajo la misma palabra conviven tres cosas distintas, y confundirlas es el origen de casi todos los problemas:

• Estar en otra subred. El dispositivo recibe una IP de otro rango. Sigue teniendo Internet, pero ya no comparte dominio de difusión con el móvil.
• Aislamiento cliente-cliente. Una opción del punto de acceso que impide que dos aparatos conectados al mismo SSID se hablen entre sí, aunque estén en la misma subred. Casi todas las redes de invitados lo traen activado de fábrica.
• Reglas de firewall. Permiten decidir con precisión qué segmento puede iniciar conexiones hacia cuál, y en qué puertos.

La clave técnica es esta: la mayor parte de la domótica local no se localiza por dirección IP, sino por anuncio. Los dispositivos se presentan en la red mediante mDNS (también llamado Bonjour) y SSDP, que son tráfico multicast. Y ese tráfico, por diseño del protocolo, no sale de su segmento. No es un fallo del router: es cómo está definido.

¿Cuáles son las tres formas de separar los dispositivos?

Red de invitados. Mismo router, otro SSID. Es gratis, está en cualquier equipo de operador y se activa en dos clics. También es, sin que nadie lo advierta, la opción más agresiva: al llevar aislamiento cliente-cliente por defecto, corta la comunicación entre el móvil y los dispositivos, no solo entre los dispositivos y el ordenador.

SSID y subred separados sin aislamiento. Los aparatos quedan en otro rango pero pueden hablarse entre ellos. Menos habitual en routers de operador, más frecuente en equipos con firmware avanzado. Rompe el descubrimiento entre segmentos, pero no dentro del segmento IoT.

VLAN con reglas de firewall. Requiere un router o unos puntos de acceso que lo soporten. Es la única opción que permite abrir exactamente lo necesario y dejar cerrado el resto. También la única que exige entender lo que se está haciendo. Si el equipo que tienes es el que instaló el operador, conviene revisar antes qué permite realmente ese router.

¿Qué sigue funcionando y qué se rompe en cada caso?

La tabla resume el comportamiento por función. «Depende» y «Requiere configuración» no son evasivas: significan que el resultado lo decide el equipo de red, no el protocolo.

Conviene leer con atención la última fila de la columna central. En una red de invitados con aislamiento, el móvil deja de ver los dispositivos aunque estés sentado en el sofá. Es el efecto que más desconcierta y el que hace que mucha gente desande el camino a los dos días.

¿Por qué el descubrimiento local es lo primero que se rompe?

Porque mDNS y SSDP están diseñados para funcionar dentro de un segmento y no fuera de él. Los anuncios mDNS viajan a una dirección multicast con un alcance deliberadamente corto: el router no los reenvía a otra subred. SSDP, que usan muchos dispositivos más antiguos, se comporta igual.

Eso tiene una consecuencia práctica: cuando separas segmentos, no basta con «abrir un puerto». Hay que instalar un reflector o repetidor mDNS —presente en firmwares como OpenWrt, OPNsense o en controladoras de red domésticas avanzadas— y añadir reglas que permitan la conversación posterior. Sin reflector, el dispositivo puede tener Internet perfecto y seguir siendo invisible para tu móvil.

Si estás aquí porque algo ya se desconecta sin haber tocado nada, el problema puede ser otro: merece la pena descartar antes las causas clásicas de desconexión nocturna y revisar la configuración WiFi de base.

¿Qué le ocurre a Home Assistant si separas la red?

Depende de dónde quede Home Assistant, y es la decisión más importante de todo el montaje.

Si Home Assistant se queda en la red principal y los dispositivos pasan al segmento aislado, las integraciones que funcionan con una IP fija y tráfico normal pueden seguir operando si el firewall lo permite. Las que dependen de autodescubrimiento dejan de encontrar nada. MQTT es el caso más agradecido: el broker tiene dirección conocida y los dispositivos se conectan hacia él, así que cruza bien entre segmentos.

La configuración que menos problemas da es la contraria: colocar Home Assistant en el mismo segmento que los dispositivos y abrir desde la red principal únicamente el acceso a su interfaz. Así el descubrimiento ocurre dentro del segmento, donde funciona sin trucos, y lo único que atraviesa el firewall es tu navegador. Si estás valorando cuánto control local necesitas de verdad, el mapa de decisión sobre domótica local plantea esa pregunta antes que la de red.

¿Funcionan los asistentes de voz con los dispositivos en otra red?

Hay que separar dos cosas que se confunden constantemente. El control por nube funciona: das la orden, el altavoz la manda a su servidor, el servidor contacta con el servidor del fabricante del enchufe y el enchufe obedece. Ninguno de esos saltos necesita que los dos aparatos se vean en tu casa. Por eso mucha gente segmenta y no nota nada raro durante días.

El control local es otra historia. Las rutas que se ejecutan sin salir a Internet, las respuestas rápidas y buena parte de los modos de funcionamiento sin conexión sí requieren que altavoz y dispositivo compartan segmento o que el descubrimiento cruce. Y el emparejamiento inicial casi siempre exige que el móvil vea el aparato: es habitual tener que unir temporalmente el teléfono a la red IoT solo para dar de alta un dispositivo nuevo.

¿Qué ocurre con Matter y Thread?

Aquí conviene ser preciso, porque circula mucha simplificación. No es cierto que Matter no funcione entre segmentos. Lo que ocurre es que impone condiciones más exigentes que un dispositivo WiFi corriente.

Matter sobre WiFi trabaja sobre IPv6 y se descubre mediante DNS-SD sobre mDNS. Para que cruce entre segmentos hacen falta tres cosas a la vez: IPv6 operativo y correctamente enrutado en ambos lados, reflexión de mDNS entre ellos, y reglas que permitan el tráfico en los dos sentidos. Si falta cualquiera de las tres, el dispositivo aparece como inalcanzable aunque tenga Internet. El emparejamiento inicial suele apoyarse en Bluetooth, que no depende de la red, y eso genera la confusión habitual: el alta funciona y el control posterior no.

Thread es un caso distinto y suele malinterpretarse. Los dispositivos Thread no están en tu WiFi: forman su propia malla de radio y llegan al resto de la casa a través de un border router. Lo que importa, por tanto, no es en qué segmento está el sensor —no está en ninguno—, sino en qué segmento está el border router y si puede anunciar sus servicios y rutas hacia donde estén los controladores. Si el border router queda en la red IoT y el controlador en la principal, reaparece exactamente el mismo problema de descubrimiento.

Zigbee y Z-Wave son más simples de razonar precisamente porque no son IP: el sensor habla con su coordinador por radio y el único que aparece en la red es el hub. La pregunta se reduce a dónde colocas ese hub. Para el estado real del estándar, el balance de Matter y la investigación sobre routers que interfieren con Zigbee cubren el detalle.

¿Y Chromecast, AirPlay y el multimedia?

Son los que peor lo llevan. Dependen por completo de Bonjour y, en el caso del casting, de conexiones directas entre el móvil y el receptor. En una red de invitados con aislamiento el icono simplemente no aparece. Con VLAN funcionan si hay reflector y reglas bien puestas, pero es donde más tiempo se pierde afinando.

La recomendación pragmática es dejar el multimedia fuera de la ecuación: el televisor y los altavoces de casting no ganan casi nada estando aislados y complican mucho el montaje. El riesgo real está en otro sitio.

¿Qué mejora de verdad en seguridad al segmentar?

Cuatro cosas concretas, y conviene nombrarlas con precisión porque el marketing de seguridad tiende a prometer más:

• Movimiento lateral. Una cámara con firmware comprometido no puede escanear tu portátil, tu NAS ni tu impresora. Este es el beneficio principal y es real.
• Visibilidad reducida. Los dispositivos dejan de inventariar lo que hay en la red, algo que varios hacen de forma rutinaria.
• Exposición de equipos personales. Los aparatos con datos sensibles quedan fuera del alcance de los aparatos baratos.
• Control del tráfico de salida. Es la ganancia más infravalorada: con reglas por segmento puedes impedir que un dispositivo que no necesita Internet salga a Internet. Sobre qué envían realmente, la investigación sobre los datos que mandan a sus servidores da la dimensión del asunto.

¿Qué problemas no resuelve segmentar?

Esto es igual de importante y casi nunca se dice. Aislar la red reduce el radio de daño, no la probabilidad de que un dispositivo acabe comprometido. No protege frente a:

• Una cuenta en la nube comprometida. Si alguien entra en tu cuenta del fabricante, controla el dispositivo desde fuera y tu VLAN es irrelevante.
• Firmware vulnerable con salida a Internet. El aparato sigue hablando con su propio servidor, que es justo por donde llegaría el problema.
• Contraseñas débiles o reutilizadas. Un segmento aparte no arregla una credencial mala.
• Un servicio del fabricante comprometido en origen. La cadena de suministro no pasa por tu router.
• El fabricante que apaga sus servidores. Ese riesgo es contractual, no de red.

Dicho de otro modo: segmentar es una medida de contención excelente y una medida de prevención mediocre. Debe ir acompañada de lo básico, que sigue siendo cambiar credenciales por defecto y mantener el firmware al día.

¿Qué configuración te conviene? Árbol de decisión

Cuatro preguntas en orden. La primera que responda «no» decide el resultado.

¿Por dónde empezar si no quieres complicarte?

Por orden de esfuerzo, y sin saltarse el primer nivel, que es el que más riesgo elimina por unidad de trabajo.

Nivel 0 — sin tocar la topología. Cambiar las credenciales por defecto, activar la verificación en dos pasos en las cuentas de fabricante, actualizar el firmware y hacer inventario de qué aparatos tienen realmente motivo para salir a Internet. La mayoría de los incidentes domésticos se explican en este nivel, no en el de red.

Nivel 1 — red de invitados selectiva. Mover únicamente lo que se controla por nube y no necesita descubrimiento: cámaras, algún enchufe, dispositivos de marcas sin soporte claro. Reversible en un minuto y sin consecuencias sobre el resto de la instalación.

Nivel 2 — VLAN con reglas. Solo si el equipamiento lo permite y estás dispuesto a mantener un reflector mDNS. A cambio se obtiene lo único que realmente vale la pena de todo esto: decidir, aparato por aparato, qué puede hablar con qué y qué puede salir fuera.

Segmentar no es una insignia. Es una decisión de arquitectura con coste. Hecha en el nivel adecuado, reduce mucho el daño posible de un dispositivo barato. Hecha por encima de tus posibilidades de mantenimiento, lo más probable es que acabes desactivándola tras la tercera automatización que deja de funcionar sin motivo aparente.