Durante una temporada pensé que la red de casa podía ir creciendo por acumulación. Un router decente, un switch gestionable, algún punto WiFi, un par de VLANs cuando hicieran falta y ya se vería. Ese “ya se vería” es el principio de casi todos los líos de red doméstica.
El homelab no vive aislado. Comparte casa con móviles, tablets, teles, consolas, enchufes inteligentes, bombillas, cámaras, impresoras, asistentes, portátiles de trabajo y familiares que solo quieren que internet funcione. Ahí está el problema. Para mí un firewall de homelab familiar no consiste en montar el panel más potente ni en copiar una arquitectura de empresa. Consiste en poner límites claros para que el laboratorio pueda romperse sin arrastrar la convivencia.
La red perfecta no existe. La red que puedes entender dentro de seis meses sí existe, y esa es la que merece la pena.
El objetivo no es tener muchas VLANs#
Una VLAN es una herramienta, no una medalla. Es fácil caer en la tentación de separar todo: servidores, IoT, invitados, cámaras, domótica, trabajo, laboratorio, almacenamiento, administración, consolas, niños, impresoras y cualquier categoría que suene profesional. El diagrama queda precioso. Luego tienes que vivir con él.
Mi criterio ahora es más simple: separo cuando hay una diferencia real de confianza o impacto.
Los dispositivos IoT no tienen la misma confianza que un portátil. Una cámara barata o una bombilla con firmware dudoso no deberían moverse por la red como si fueran de la familia. El laboratorio tampoco debería tener acceso libre a todo. Si estoy probando contenedores, VMs, herramientas de red o servicios expuestos, quiero que esa zona tenga libertad para romperse pero no para tocar lo importante.
Los servicios familiares son otra categoría. DNS, Home Assistant, fotos, documentos, backups, gestores de contraseñas o acceso remoto estable. Si algo de eso cae, molesta. Si algo de eso se compromete, duele. Por eso no lo trato igual que una VM de pruebas que he levantado a medianoche con más entusiasmo que juicio.
Mi mínimo sensato suele quedar así:
- Red principal para móviles, portátiles y equipos de confianza.
- Red de servicios para servidores domésticos estables.
- Red IoT para cacharros poco fiables.
- Red de laboratorio para pruebas.
- Red de invitados si entra gente en casa con frecuencia.
Con eso ya cubro el 90% de los casos sin construir un laberinto.
La regla que más evita sustos#
La regla base es aburrida: negar por defecto entre redes y permitir solo lo necesario.
No hace falta ponerse paranoico. Hace falta ser explícito. Si la red IoT necesita hablar con Home Assistant, se permite lo justo. Si la red principal necesita acceder a los servicios internos, se permite. Si el laboratorio necesita salir a internet, perfecto. Si el laboratorio quiere hablar con el NAS donde viven las copias buenas, que pida cita.
El error típico es crear VLANs y luego permitir tráfico entre todas porque algo no funciona. Eso es decoración de seguridad. Has metido etiquetas y colores, pero la red sigue siendo una sopa.
En casa prefiero reglas muy pocas y muy legibles:
- La red principal puede acceder a servicios domésticos.
- La red de servicios puede salir a internet para actualizarse.
- IoT solo puede salir a internet y hablar con los servicios concretos que necesita.
- Invitados solo internet.
- Laboratorio solo internet y acceso puntual hacia recursos aprobados.
- Administración del firewall, switches y Proxmox solo desde una zona de confianza.
No uso nombres heroicos para las reglas. Las llamo como las entendería medio dormido. “LAN a servicios”, “IoT a Home Assistant”, “invitados a internet”, “bloquear laboratorio a NAS”. Si necesitas abrir el firewall dentro de tres meses, agradecerás no haber escrito poesía técnica.
IoT: el invitado que nunca se va#
La red IoT es donde más se nota la diferencia entre teoría y casa real.
En teoría, todos los dispositivos IoT deberían estar aislados, sin acceso a nada salvo internet, y con reglas estrictas. En la práctica, algunos necesitan descubrimiento local, otros hablan con hubs, otros dependen de apps móviles, otros usan multicast, otros se enfadan si los miras raro. Separarlos bien requiere paciencia.
Mi enfoque es gradual. Primero meto los dispositivos más sospechosos o menos necesarios en la red IoT: enchufes baratos, cámaras, teles, aparatos que no actualizo con frecuencia, dispositivos que no necesitan ver mis portátiles ni mis servidores. Luego voy moviendo lo demás cuando sé qué rompe.
Aquí mDNS suele aparecer como el demonio pequeño. AirPlay, Chromecast, impresoras, apps móviles y algunos descubrimientos locales dependen de broadcast o multicast. Si separas redes, parte de esa magia desaparece. Puedes resolverlo con repetidores mDNS o reglas concretas, pero conviene hacerlo con intención. No todo tiene que descubrirlo todo.
Para Home Assistant, suelo permitir tráfico desde IoT hacia Home Assistant solo en los puertos necesarios, y desde Home Assistant hacia IoT cuando toca controlar dispositivos locales. No quiero que una bombilla pueda iniciar conversación con el NAS, con Proxmox o con el portátil de trabajo. Una bombilla no tiene nada que decirle a un hipervisor. Sospechoso, como mínimo.
Laboratorio: libertad con una valla#
El laboratorio necesita margen. Si cada prueba requiere abrir tres tickets mentales, dejas de probar. Y si no pruebas, el homelab pierde media gracia.
Pero libertad no significa barra libre. Mi red de laboratorio debe poder romperse entera sin afectar a casa. Ahí levanto VMs temporales, clusters raros, proxies nuevos, herramientas de monitorización, servicios que quizá no sobrevivan al fin de semana y cosas que prefiero no tener cerca de producción doméstica.
La regla importante es que el laboratorio no vea por defecto los servicios críticos. Puede salir a internet. Puede recibir acceso desde mi equipo principal. Puede hablar con un repositorio Git o con un registro de contenedores si hace falta. Pero no debería montar el almacenamiento familiar como si fuera una carpeta de pruebas.
Esto también ayuda psicológicamente. Cuando sé que una zona está vallada, pruebo más tranquilo. Puedo reinstalar, borrar, cambiar rutas, romper DNS interno de laboratorio o levantar un proxy absurdo sin preguntarme si acabo de fastidiar las fotos de la familia.
Un homelab sano necesita un sitio para hacer el bruto. Solo que ese sitio no debería ser la red principal.
Servicios domésticos: pocos caminos, bien conocidos#
La red de servicios es donde pongo lo que tiene valor real. No todo lo que corre en un servidor merece estar aquí. Para mí entran DNS interno, Home Assistant si es estable, gestor de contraseñas, backups, documentos, fotos y monitorización básica.
Esta zona tiene dos prioridades: estabilidad y recuperación.
El firewall ayuda, pero no sustituye backups ni actualizaciones. Separar servicios en una VLAN no arregla una base de datos sin copia, ni un contenedor abandonado, ni una contraseña mala. La segmentación reduce daños laterales. No convierte un servicio descuidado en seguro.
También intento que el acceso administrativo sea distinto del acceso de uso. Una cosa es que un móvil pueda entrar a la interfaz web de fotos o recetas. Otra es que pueda administrar el host, el panel de contenedores o el firewall. Cuanto menos expuesto esté el plano de control, menos posibilidades tengo de liarla.
Aquí una regla que me gusta mucho es permitir acceso de administración solo desde mi equipo principal o desde una red de gestión concreta. No siempre hace falta una VLAN dedicada de gestión en una casa, pero sí hace falta pensar quién puede tocar botones peligrosos.
El DNS manda más de lo que parece#
Cuando separas redes, el DNS se vuelve infraestructura crítica de verdad. Ya no es solo resolver webs. También decide cómo accedes a servicios internos, qué nombres existen y qué pasa cuando algo falla.
Yo prefiero nombres internos claros. Nada de memorizar direcciones. Un servicio importante debería tener un nombre estable tipo fotos.home.arpa o backup.home.arpa. El dominio puede variar, pero la idea es la misma: nombres que no dependan de acordarte de qué IP pusiste una noche.
También conviene decidir qué redes pueden resolver nombres internos. La red principal, sí. La red de servicios, sí. La red de laboratorio, quizá solo algunos. Invitados, normalmente no. IoT, solo si hace falta.
El DNS también tiene que tener plan B. Si todo internet en casa depende de un único contenedor que vive en el mismo host que estás reiniciando, has construido una pequeña trampa. Puedes usar dos resolvers, un fallback en el router o una política muy clara para que la casa no se quede muda cada vez que tocas el homelab.
No hay nada que baje más el prestigio doméstico de un homelab que dejar sin internet a la casa por actualizar una cosa que nadie pidió.
pfSense, OPNsense o router comercial#
He probado el enfoque de firewall serio en casa y también entiendo a quien prefiere un router comercial decente. No todo el mundo necesita pfSense u OPNsense.
pfSense y OPNsense tienen sentido si quieres VLANs, reglas claras, VPN, DHCP avanzado, DNS, logs, múltiples interfaces, reglas por alias y control fino. Son potentes y muy cómodos cuando ya estás dentro de esa forma de trabajar. También añaden responsabilidad. Si el firewall vive en una VM y esa VM cae, la casa puede quedarse sin red. Si haces cambios sin backup de configuración, te puedes regalar una tarde preciosa.
Un router prosumer con VLANs puede ser suficiente para mucha gente. UniFi, MikroTik, TP-Link Omada y similares cubren muchísimos casos domésticos. Pierdes algo de flexibilidad, ganas integración y menos piezas sueltas.
Mi recomendación sería esta: si estás empezando, no conviertas el firewall en el primer monstruo del homelab. Empieza con una separación simple, reglas entendibles y backups de configuración. Ya habrá tiempo para complicarse.
Cómo lo montaría desde cero#
Si tuviera que plantearlo hoy desde cero, iría por fases.
Primero haría inventario. Qué dispositivos hay, qué servicios existen, quién los usa y qué pasaría si caen. Sin inventario, las VLANs se diseñan con fantasía.
Después crearía solo dos separaciones iniciales: principal e invitados o principal e IoT, según el dolor más claro. Movería pocos dispositivos y comprobaría qué rompe. Nada de migrar toda la casa en una tarde de heroísmo.
La siguiente fase sería separar servicios estables y laboratorio. Ahí ya cambia la calidad del homelab. Tener una zona donde viven las cosas serias y otra donde rompes sin culpa es una mejora enorme.
Luego documentaría las reglas. No una biblia. Una lista simple: redes, propósito, qué puede hablar con qué y por qué. Si una regla no puedes explicar en una frase, quizá está mal planteada.
Por último, haría backup de la configuración del firewall y del switch. Esto se olvida mucho. Si pierdes el firewall y no sabes reconstruir VLANs, DHCP, reservas, DNS y reglas, tienes un puzzle justo cuando menos apetece.
Errores que evitaría#
El primero: demasiadas VLANs demasiado pronto. Complica más de lo que protege.
El segundo: permitir todo entre redes para arreglar descubrimiento local. Si algo necesita mDNS o un puerto concreto, se resuelve eso, no se abre la muralla entera.
El tercero: poner el firewall virtualizado sin pensar en el arranque. Virtualizar pfSense u OPNsense puede funcionar muy bien, pero si el host depende de esa red para levantarse o para montar almacenamiento, puedes crear una dependencia circular bastante antipática.
El cuarto: olvidarse de la familia. Si cada visita necesita soporte técnico para conectarse al WiFi, la arquitectura ha ganado en elegancia y perdido en humanidad. Mala operación.
El quinto: no probar cortes. Apaga un nodo, reinicia el firewall en una ventana tranquila, comprueba que sabes volver. Mejor descubrir el fallo un domingo por la mañana que un lunes a las nueve.
Mi conclusión#
Un firewall familiar para homelab no tiene que parecerse a una empresa pequeña. Tiene que proteger lo importante sin convertir la casa en un laboratorio permanente.
Para mí la buena arquitectura es la que separa confianza, reduce daños y sigue siendo comprensible. IoT en su sitio. Laboratorio con valla. Servicios domésticos cuidados. Invitados lejos de todo. Administración desde pocos sitios. DNS con plan B. Reglas pocas y con nombres humanos.
No es la red más impresionante. Es mejor: es una red que puedes mantener sin odiarte.