Las VLANs en casa son una de esas cosas que empiezan como una mejora sensata y pueden acabar como una pequeña religión. Separar invitados, IoT, servidores y dispositivos personales tiene sentido. Lo que no tiene tanto sentido es montar una red tan fina que cada vez que alguien quiere imprimir, enviar contenido a la tele o configurar una bombilla, aquello parezca una auditoría de seguridad.
He pasado por esa fase. Mirar diagramas, pensar en segmentos perfectos, imaginar reglas limpias, dejarlo todo dividido como si en casa hubiera un equipo de redes esperando tickets. Luego llega la realidad: un móvil no ve la impresora, una app de domótica necesita descubrir un dispositivo por mDNS, una tele quiere hablar con el móvil, un altavoz se queda medio tonto y tú acabas abriendo reglas a mano mientras murmuras cosas poco publicables.
Por eso ahora planteo las VLANs domésticas con una idea bastante simple: separar lo que reduce riesgo sin romper lo que la casa necesita usar.
No busco una red perfecta. Busco una red mantenible.
Por qué separar invitados e IoT#
La red de invitados es fácil de justificar. Alguien viene a casa, necesita WiFi y no tiene por qué estar en la misma red que tus portátiles, NAS, impresoras, cámaras, servidores y cacharros varios. No es desconfianza personal. Es higiene básica.
IoT también merece separación. Bombillas, enchufes, televisores, cámaras, altavoces, aspiradores, sensores y aparatos similares suelen tener tres problemas: se actualizan cuando quieren, hablan con servicios externos que no controlas y muchas veces viven años sin que nadie revise nada. Algunos son decentes. Otros son cajas negras con WiFi.
Meter todo eso en la misma LAN donde tienes portátiles, backups y servicios internos es cómodo, pero no me gusta. Si un dispositivo IoT se compromete o empieza a hacer cosas raras, prefiero que su radio de acción sea pequeño.
Ahora bien, separar no significa aislarlo todo hasta que nada funcione. En una casa hay dependencias legítimas. El móvil controla luces. Home Assistant habla con dispositivos. La tele recibe contenido. Una impresora puede necesitar acceso desde varias redes. La clave está en permitir flujos concretos, no en abrir la puerta entera porque algo falló una vez.
Mi diseño mínimo#
Para una casa normal con homelab, yo empezaría con pocas redes:
- LAN principal para portátiles, móviles personales y dispositivos de confianza.
- IoT para dispositivos conectados que no necesitan ver toda la casa.
- Invitados para gente que solo necesita Internet.
- Servidores o homelab si tienes servicios internos con entidad propia.
Con eso ya tienes bastante. Podrías añadir cámaras, laboratorio, trabajo, consolas, impresoras o mil segmentos más. A veces tiene sentido. Pero cada VLAN adicional cobra mantenimiento. Hay que pensar DHCP, DNS, reglas, mDNS, rutas, nombres, monitorización y resolución de problemas.
Mi sesgo actual es empezar simple y separar más solo cuando hay una razón clara. Una VLAN que no sabes explicar en una frase probablemente sobra.
Por ejemplo:
- Invitados: salen a Internet y no ven redes internas.
- IoT: sale a Internet si hace falta y solo habla con Home Assistant o servicios concretos.
- LAN: puede iniciar conexiones hacia IoT cuando hace falta.
- Servidores: exponen solo los servicios internos necesarios.
Eso cubre mucho sin convertir la red en una maqueta de certificación.
La regla que más uso#
La regla mental es esta: las redes menos confiables no inician conexiones hacia las más confiables.
Invitados no hablan con LAN. IoT no habla con portátiles ni NAS. IoT puede hablar con Internet si el dispositivo lo necesita, aunque en algunos casos conviene limitarlo. LAN sí puede iniciar conexiones hacia IoT para administración o uso normal. Home Assistant puede hablar con IoT porque esa es su función.
Esta dirección importa más que el número exacto de VLANs. Mucha gente separa redes y luego abre reglas enormes porque algo deja de funcionar. Al final tiene más complejidad y casi la misma exposición que antes.
Yo prefiero pocas reglas con intención clara:
- Invitados a Internet.
- Invitados bloqueado hacia redes privadas.
- IoT a Internet si es necesario.
- IoT bloqueado hacia LAN y servidores, salvo excepciones concretas.
- Home Assistant hacia IoT.
- LAN hacia servicios internos y, cuando haga falta, hacia IoT.
- Servidores con entrada limitada a puertos concretos.
El matiz está en las excepciones. No pasa nada por tener excepciones. Lo peligroso es no saber por qué existen.
mDNS: el pequeño infierno amable#
Si montas VLANs en casa, tarde o temprano aparece mDNS. AirPlay, Chromecast, impresoras, algunos dispositivos de domótica y un montón de apps dependen de descubrimiento local. Funcionan de maravilla cuando todo está en la misma LAN. En cuanto separas redes, empiezan los “no aparece”.
Aquí hay dos caminos. Puedes activar reflejo mDNS entre redes, si tu router o firewall lo soporta. O puedes aceptar que algunos dispositivos vivan juntos porque separarlos rompe más de lo que aporta.
Yo intento no ser dogmático. Si una tele o un altavoz necesita estar en una red concreta para que la familia lo use sin problemas, lo valoro. No todo dispositivo que huele a IoT tiene que vivir aislado a cuchillo. A veces la solución más sensata es poner ciertos dispositivos multimedia en una red donde funcionen bien, con reglas razonables, y reservar la VLAN IoT estricta para dispositivos que no necesitan descubrimiento cómodo.
El objetivo no es ganar una discusión en un foro. Es que la casa funcione mejor y con menos riesgo.
IoT sin acceso lateral#
Lo que sí intento evitar es que IoT tenga acceso lateral libre. Una bombilla no necesita hablar con mi NAS. Un aspirador no necesita ver el panel de Proxmox. Una cámara no debería poder iniciar conexiones hacia el portátil.
La mayoría de dispositivos IoT necesitan tres cosas:
- DHCP para obtener IP.
- DNS para resolver nombres.
- Internet para su nube, si no son locales.
- Acceso desde Home Assistant o desde el móvil, según el caso.
Sí, son cuatro. Las listas perfectas son sospechosas.
Con eso basta para muchos casos. Si un dispositivo pide más, lo miro. A veces es legítimo. A veces es una app mal diseñada. A veces es que la configuración inicial necesita estar en la misma red y luego ya no.
Una práctica que me funciona es configurar primero el dispositivo en una red temporal cómoda, entender qué necesita y luego moverlo a IoT. No siempre se puede, pero evita abrir reglas a ciegas.
Invitados: Internet y poco más#
La red de invitados debería ser aburrida. Internet, DNS y nada más.
No le daría acceso a impresoras, servidores ni dispositivos internos salvo una necesidad muy concreta. Y si esa necesidad aparece a menudo, quizá no es una red de invitados, sino otra cosa. Por ejemplo, una red de trabajo para alguien que vive en casa y necesita recursos concretos.
También me gusta que la red de invitados tenga contraseña separada y, si el sistema lo permite, aislamiento entre clientes. Esto evita que dos dispositivos invitados se vean entre sí. No es una defensa mágica, pero reduce superficie.
En casas donde viene mucha gente, tener QR para la WiFi de invitados es cómodo. Lo importante es que esa comodidad no acabe siendo “te doy la clave de la LAN principal porque total”. Esa frase es el principio de muchas redes desordenadas.
DNS en redes separadas#
DNS parece un detalle, pero es una pieza central en una red con VLANs. Puedes hacer dos cosas: dar a todas las redes el mismo DNS interno o dar DNS distinto según segmento.
Yo prefiero que todas usen un DNS controlado, pero con cuidado. Invitados no necesitan resolver nombres internos. IoT quizá necesita resolver algunos servicios, pero no todos. LAN sí puede resolver nombres del homelab.
Si el DNS interno cae, no quiero que toda la casa se quede inútil. Esto lo he dicho muchas veces porque es una de las averías más tontas y más molestas. Si tu diseño de seguridad depende de un DNS casero, ten plan B.
También evitaría depender demasiado de nombres .local para cosas serias. Para cuatro dispositivos va bien. Para un homelab con servicios, split DNS y nombres claros son menos vistosos pero más sanos.
Un ejemplo razonable:
router.localo equivalente para el gateway.homeassistant.casapara domótica.nas.casapara almacenamiento.grafana.casaostatus.casapara monitorización.
No hace falta publicar nada fuera. Solo necesitas una convención que puedas recordar dentro de seis meses.
Home Assistant como puente controlado#
Home Assistant suele ser el motivo por el que una VLAN IoT no puede estar completamente aislada. Tiene que hablar con luces, enchufes, sensores, televisores, integraciones locales y a veces servicios cloud.
Mi enfoque es tratar Home Assistant como un puente controlado, no como excusa para abrir todo.
Si Home Assistant vive en la red de servidores, permito que hable hacia IoT en los puertos necesarios. IoT no necesita iniciar conexiones hacia toda la red de servidores. Si algún dispositivo lo requiere, intento entenderlo antes de abrir.
También conviene pensar qué pasa si Home Assistant cae. Las luces básicas deberían seguir teniendo alguna forma de uso manual. Si una automatización falla, la casa no debería quedar en modo escape room. La domótica mola hasta que una persona normal no puede encender una luz porque tú decidiste que todo pasara por una VM.
Cámaras y dispositivos delicados#
Las cámaras merecen párrafo aparte. No las trataría igual que una bombilla.
Si tienes cámaras IP, yo las pondría en una red separada o en IoT con reglas más estrictas. Idealmente no tendrían salida a Internet si no es necesaria. El grabador o NVR puede hablar con ellas. Tú puedes ver el NVR. Las cámaras no necesitan pasearse por la red.
Esto aplica también a dispositivos con datos sensibles o micrófonos permanentes. No hace falta entrar en paranoia, pero tampoco regalarles acceso total por comodidad.
El problema en casa es que cada fabricante hace las cosas a su manera. Algunos dispositivos funcionan bien en local. Otros dependen de su nube para respirar. Ahí toca decidir si aceptas esa dependencia o si compras otra cosa. La mejor regla de firewall no arregla un producto que ya parte de una premisa mala.
El error de abrir demasiado pronto#
Cuando algo no funciona entre VLANs, la tentación es abrir rangos enteros para probar. Lo haces, funciona y luego se queda así. Meses después tienes una regla llamada “TEMP TEST” que permite media red porque nadie se atreve a tocarla.
Mejor probar de forma acotada.
Primero identifico quién inicia la conexión. No es lo mismo móvil a tele que tele a móvil. Luego miro si el problema es descubrimiento, DNS, puerto bloqueado o una app que espera misma subred. Después abro lo mínimo necesario y lo documento con una descripción que entienda mi yo del futuro.
Si no sé qué hace una regla, es mala señal. Puede que sea necesaria, pero entonces necesita comentario. En redes domésticas, la documentación no tiene que ser perfecta. Tiene que evitar que dentro de seis meses rompas algo por limpiar una regla que parecía absurda.
Cuándo no usaría VLANs#
También hay casos donde no metería VLANs todavía.
Si tu red es un router de operadora, dos móviles, una tele y un portátil, quizá una WiFi de invitados basta. Si no tienes firewall gestionable ni switch decente, forzar VLANs puede salir caro en tiempo y hardware. Si no sabes diagnosticar una ruta básica, quizá primero conviene entender DHCP, DNS y subredes antes de dividirlo todo.
No lo digo como puerta cerrada. Se aprende montando. Pero empezar por una arquitectura demasiado compleja puede hacer que cualquier fallo parezca magia negra.
Una ruta más sana sería:
- WiFi principal y WiFi de invitados.
- DNS interno sencillo.
- Separar IoT cuando tengas firewall y puntos de acceso que lo hagan bien.
- Añadir red de servidores si el homelab crece.
- Afinar reglas según problemas reales.
La seguridad doméstica tiene que poder mantenerse cansado. Si solo puedes administrarla un sábado inspirado, está sobrediseñada.
Cómo lo validaría#
Después de separar redes, no me quedaría mirando solo el panel del firewall. Validaría casos reales:
- Un invitado se conecta y navega, pero no ve servicios internos.
- Un móvil de la LAN controla la domótica.
- Home Assistant ve los dispositivos IoT que debe ver.
- La tele o altavoz aparece donde tiene que aparecer.
- La impresora funciona desde los dispositivos que la necesitan.
- Los servidores internos no son accesibles desde invitados.
- DNS resuelve lo que toca en cada red.
- Si cae el DNS interno, hay un plan razonable para recuperar Internet.
Esto parece básico, pero es donde se descubre casi todo. Una red puede estar preciosa en el diagrama y ser insoportable en la vida diaria.
Mi conclusión#
Sí, separaría invitados e IoT en una casa con homelab. Lo haría sin dudar. Pero no montaría una red doméstica como si cada enchufe fuera un atacante de élite.
El diseño bueno es el que reduce riesgo y sigue siendo usable. Invitados aislados. IoT con salida controlada. LAN con acceso a lo que necesita. Home Assistant como puente, pero no como agujero negro de reglas. DNS claro. mDNS tratado con respeto, porque si lo ignoras te va a cobrar la factura.
La red perfecta no existe. La red que puedes entender, mantener y explicar cuando algo falla vale mucho más.
Y si una VLAN nueva hace que la casa funcione peor, no has mejorado la seguridad. Has comprado una discusión futura con lucecitas en el switch.