Un firewall doméstico se puede estropear de dos maneras. La obvia es abrir demasiado. La más habitual es abrir cosas sin acordarte después de por qué lo hiciste. Una excepción para que funcione una tele. Otra para que Home Assistant descubra un dispositivo. Otra para probar un contenedor. Otra porque una impresora decidió comportarse como si la red fuese un club privado. Seis meses después miras la lista de reglas y aquello parece escrito por alguien que sabía lo que hacía, pero no dejó ninguna pista.
Ese alguien suele ser uno mismo. Qué cómodo.
Este artículo encaja en la ruta de red y acceso remoto. Ya he hablado de separar laboratorio, IoT y servicios con un firewall familiar y de diseñar una red doméstica con servicios críticos, LAN, IoT y VPN. Aquí bajo un nivel más práctico: cómo escribir reglas que pueda entender cuando vuelva a abrir el panel dentro de medio año.
No va de copiar una plantilla perfecta de pfSense, OPNsense, UniFi o MikroTik. Cada casa tiene sus rarezas. Va de tener una política pequeña, explícita y mantenible.
El problema real no son las VLANs#
Las VLANs suelen llevarse toda la atención porque son visibles. Creas redes, eliges nombres, separas dispositivos y el diagrama empieza a parecer serio. Pero una VLAN sin reglas claras es solo una etiqueta.
Lo que decide si la red está bien planteada es el flujo permitido entre zonas. Quién puede iniciar conexión. Hacia dónde. En qué puertos. Con qué motivo. Y, sobre todo, qué queda bloqueado por defecto.
La parte delicada es que en casa no estamos diseñando para una oficina con políticas cerradas. Hay móviles, teles, consolas, impresoras, altavoces, cámaras, bombillas, servidores, portátiles de trabajo, invitados y servicios familiares. Algunos dispositivos necesitan descubrirse entre sí. Otros deberían tener internet pero no ver nada local. Otros guardan datos que no quiero exponer a una bombilla con firmware dudoso.
Por eso prefiero pensar en zonas de confianza antes que en marcas o menús:
- Casa: móviles, portátiles y equipos de confianza.
- Servicios: NAS, DNS, Home Assistant, documentos, fotos, backups.
- IoT: dispositivos que necesitan funcionar, pero no merecen confianza plena.
- Invitados: solo internet.
- Laboratorio: pruebas, VMs temporales, contenedores raros.
- Gestión: firewall, switches, hipervisores y paneles sensibles.
No siempre necesitas todas. Si estás empezando, dos o tres zonas bien pensadas ganan a ocho VLANs mantenidas con miedo.
Mi regla base#
La regla base es esta: permitir cerca del origen, negar lo que no tenga motivo y escribir cada excepción como si fuese a leerla otra persona.
En pfSense, la documentación de Netgate explica que las reglas de las pestañas de interfaz se aplican en la dirección de entrada de esa interfaz y que el tráfico permitido crea estado para las respuestas. OPNsense documenta también el orden de procesado de reglas y el peso de las reglas flotantes, grupos e interfaces. El resumen práctico para casa es simple: piensa desde dónde nace la conexión.
Si un móvil de la LAN quiere entrar a Paperless, la regla vive en la zona desde la que sale ese móvil. Si una cámara IoT necesita hablar con Home Assistant, la regla debería estar cerca de IoT. Si el laboratorio no debe tocar el NAS, bloquéalo donde entra el tráfico del laboratorio, no lo persigas por media red.
Esto ayuda mucho a leer el firewall. Abres una interfaz y ves qué pueden hacer los dispositivos de esa zona. No tienes que reconstruir mentalmente todo el camino.
Mi patrón habitual:
- Permitir DNS hacia los resolvers internos o externos definidos.
- Permitir DHCP si aplica.
- Permitir internet donde tenga sentido.
- Permitir accesos concretos hacia servicios internos.
- Bloquear redes internas no permitidas.
- Registrar solo lo que ayude a diagnosticar.
No hace falta que todas las reglas estén escritas así, pero sí que haya una intención reconocible.
Nombres de reglas que sirven para operar#
El nombre de una regla no es decoración. Es una nota operativa comprimida.
Malo:
| |
Mejor:
| |
No busco nombres bonitos. Busco nombres que reduzcan dudas. Si una regla se llama “Temp”, debería tener fecha de caducidad o desaparecer. Si una regla permite any hacia una red interna, el comentario tiene que justificarlo muy bien. Y si no puedes explicar una regla en una frase, probablemente no está lista.
También me gusta añadir motivo en descripción cuando la interfaz lo permite:
| |
Ese tipo de frase parece poca cosa, hasta que seis meses después alguien pregunta por qué una TV puede hablar con un servidor. La respuesta ya está ahí.
Reglas por zonas, no por cacharro suelto#
Una red doméstica se vuelve inmanejable si cada dispositivo acaba teniendo su propia colección de permisos. Al principio funciona. Luego cambias una tele, entra una consola nueva, un móvil se renueva, una cámara se sustituye y el firewall acumula cadáveres.
Prefiero reglas por grupos siempre que puedo:
- Red principal a servicios web internos.
- IoT a Home Assistant en puertos concretos.
- Invitados a internet.
- Laboratorio a internet.
- Equipo de administración a paneles sensibles.
Luego uso excepciones por dispositivo solo cuando hay una razón real. Por ejemplo, una impresora que debe recibir trabajos desde la LAN, una consola que necesita algo concreto, una cámara local que graba hacia un NVR o un Apple TV que requiere tráfico hacia el servidor multimedia.
La diferencia parece pequeña, pero cambia el mantenimiento. Una regla por zona explica una política. Una regla por dispositivo explica un parche.
Los parches son inevitables. Lo malo es cuando toda la política acaba siendo una colección de parches.
IoT: permitir lo justo sin romper la casa#
IoT es la zona donde más tentación hay de rendirse. Separas dispositivos, algo deja de descubrirse, una app no encuentra la tele, AirPlay no aparece, una impresora desaparece, y la solución rápida es abrir IoT hacia la LAN. Funciona. También convierte la separación en teatro.
Yo lo haría al revés. Primero bloqueo IoT hacia redes internas. Luego abro solo lo necesario:
- DNS hacia el resolver permitido.
- NTP si no lo resuelve el propio router.
- Salida a internet si el dispositivo la necesita.
- Acceso hacia Home Assistant cuando sea imprescindible.
- Acceso hacia NVR o servidor multimedia si aplica.
- mDNS o reflector solo si sé qué dispositivos lo necesitan.
La parte de descubrimiento local merece paciencia. mDNS, SSDP, Chromecast, AirPlay y ciertas impresoras pueden requerir reglas o repetidores. No abriría toda la red por no dedicar veinte minutos a entender qué protocolo falta.
También conviene separar “control” de “descubrimiento”. Que un móvil descubra un altavoz no significa que todos los dispositivos IoT deban iniciar conexiones hacia todos los portátiles. La comodidad tiene grados. La barra libre no es uno aceptable.
Invitados: aburrido es perfecto#
La red de invitados debería ser la más aburrida del firewall.
Para mí, invitados significa:
- Internet.
- DNS permitido.
- Nada hacia redes internas.
- Nada hacia administración.
- Nada hacia servicios familiares.
Si hay una impresora compartida o algún dispositivo que deba usarse desde invitados, lo pondría como excepción muy concreta. Pero por defecto, quien entra en la WiFi de invitados no necesita ver el NAS, Proxmox, Home Assistant ni el panel del router.
Esto no es desconfianza dramática. Es higiene. Un portátil invitado puede estar infectado, desactualizado o simplemente mal configurado. No tiene sentido darle visibilidad interna por cortesía.
Aquí las soluciones tipo UniFi suelen ser cómodas. La documentación oficial de Ubiquiti habla de políticas de tráfico y reglas avanzadas para gateways UniFi. Para muchas casas, una red de invitados bien aislada desde el propio controlador ya resuelve mucho sin montar un firewall más complejo.
Laboratorio: salida libre, entrada controlada#
La zona de laboratorio necesita respirar. Si cada prueba requiere tocar cinco reglas, no vas a probar nada. Pero tampoco quiero que una VM temporal tenga acceso libre a los datos familiares.
Mi política para laboratorio suele ser:
- Puede salir a internet.
- Puede resolver DNS.
- Puede acceder a repositorios, imágenes y recursos de desarrollo necesarios.
- No puede iniciar conexiones hacia servicios familiares.
- No puede administrar infraestructura.
- Solo recibe acceso desde mi equipo de confianza o desde una red de gestión.
Si una prueba necesita hablar con el NAS, abro una excepción temporal y la nombro como temporal. Si necesita hablar con una base de datos real, me lo pienso dos veces. Si necesita tocar el firewall, quizá no debería vivir en laboratorio.
La gracia de esta zona es psicológica y operativa. Puedo romper cosas sin miedo a romper lo que usa la casa. Eso hace que el homelab siga siendo divertido, que también importa.
Gestión: pocos orígenes y cero costumbre de entrar desde cualquier sitio#
Los paneles de administración deberían tener menos caminos que las aplicaciones normales.
No quiero administrar el firewall desde invitados. Tampoco desde IoT. Tampoco desde una VM random del laboratorio. No quiero que el panel de Proxmox, el NAS, los switches o el orquestador de contenedores estén accesibles desde cualquier red solo porque resulta cómodo.
Mi regla preferida:
- Administración solo desde el equipo principal.
- O desde una red de gestión.
- O desde VPN privada si estoy fuera.
Esto reduce muchísimo el daño de un dispositivo comprometido o de una regla mal pensada. Un servicio web familiar puede ser accesible desde la LAN. El panel que permite borrar volúmenes, reiniciar hosts o tocar VLANs no debería tener la misma exposición.
También aplicaría aquí una idea sencilla: si una interfaz no se usa para administrar, no debería poder administrar. Parece obvio. En muchos homelabs no lo es.
Logs: registrar menos, mirar mejor#
Registrar todo suena responsable hasta que el firewall se convierte en una máquina de ruido. Si cada paquete bloqueado aparece en logs, acabas ignorándolo todo.
Yo registraría:
- Bloqueos entre zonas internas que no esperaba.
- Intentos hacia administración.
- Reglas temporales mientras las pruebo.
- Tráfico raro desde IoT o laboratorio.
- Bloqueos que estoy diagnosticando.
No registraría cada paquete descartado de internet si no aporta nada. Tampoco convertiría los logs del firewall en una novela diaria. Para operar en casa, quiero señales que me ayuden a responder preguntas concretas:
- ¿Por qué esta app no descubre el dispositivo?
- ¿Qué intenta tocar esta cámara?
- ¿El laboratorio está intentando entrar al NAS?
- ¿Una regla nueva está bloqueando algo útil?
Cuando la regla ya está estable y no necesito el ruido, quito logging salvo que tenga un motivo para conservarlo.
Excepciones con fecha de revisión#
Las excepciones son necesarias. El problema es dejarlas vivir para siempre.
Me gusta tratarlas como deuda pequeña:
| |
Si una excepción temporal sobrevive tres meses, o se convierte en política o se elimina. Lo peor es ese punto intermedio donde nadie sabe si sigue haciendo falta.
Esto va muy unido al inventario del homelab y al mantenimiento mensual. Revisar reglas no debería ser una auditoría épica. Debería ser una parte pequeña del repaso: temporales, any, administración, logs y reglas sin comentario.
Orden de reglas y lectura humana#
El orden importa. En muchos firewalls, la primera regla que coincide gana. OPNsense documenta el orden por secciones y Netgate explica la lógica de reglas por interfaz en pfSense. En la práctica, si pones reglas amplias arriba, las reglas finas de abajo quizá nunca se ejecutan.
Por eso me gusta ordenar así:
- Permisos muy específicos.
- Bloqueos importantes y explícitos.
- Permisos generales de salida.
- Bloqueos finales.
No es una ley universal, pero ayuda a leer. Si necesito permitir IoT hacia Home Assistant, esa regla está cerca de las reglas de IoT. Si quiero bloquear IoT hacia redes internas, está después de los permisos concretos y antes de cualquier salida amplia que pueda taparlo.
También evitaría mezclar demasiadas reglas flotantes, grupos e interfaces si no hace falta. Las reglas flotantes tienen su sitio, pero en una casa pueden volver la lectura más difícil. Si el objetivo es mantenerlo con poca energía mental, prefiero reglas cerca de la interfaz correspondiente y nombres claros.
Un ejemplo de política sencilla#
Una política doméstica pequeña podría quedar así:
| |
Esto no cubre cada casa. Pero se entiende. Y esa es la mitad del valor.
Pruebas antes de darlo por bueno#
Después de tocar reglas, pruebo flujos reales. No me basta con que el panel guarde la configuración.
Pruebas mínimas:
- Un portátil de LAN accede a servicios internos.
- Un dispositivo IoT conserva lo que necesita.
- Un invitado no ve redes internas.
- Una VM de laboratorio no llega al NAS.
- El equipo de administración entra a paneles sensibles.
- Un móvil fuera de casa entra por VPN o acceso remoto privado.
- DNS funciona si reinicio el servicio principal o activo el plan B.
También reviso logs durante unos minutos. Si una regla nueva bloquea algo útil, prefiero verlo al momento. Si una regla permite demasiado, prefiero detectarlo antes de olvidarla.
No haría estos cambios a las once de la noche. Ya he aprendido esa lección en demasiadas áreas. La red de casa se toca cuando hay margen para arreglarla sin convertir la cena en soporte técnico.
Qué revisaría cada mes#
En la revisión mensual del homelab miraría cinco cosas del firewall:
- Reglas temporales que siguen vivas.
- Reglas con
anydemasiado amplio. - Acceso a administración desde zonas no deseadas.
- Logs nuevos o bloqueos repetidos.
- Dispositivos que cambiaron de zona o ya no existen.
No hace falta revisar cada paquete. Hace falta que la política siga contando una historia coherente. Si las reglas ya no reflejan cómo está la casa, el firewall empieza a mentir.
Y un firewall que miente es peor que uno simple. El simple sabes que es simple. El otro te da confianza falsa.
Fuentes útiles#
Para bajar a configuración concreta, miraría siempre documentación primaria antes que copiar reglas de un foro:
- OPNsense: Firewall rules
- Netgate pfSense: Rule Methodology
- Netgate pfSense: Configuring Firewall Rules
- Ubiquiti: Traffic and Policy Management in UniFi
- Ubiquiti: UniFi Gateway Advanced Firewall Rules
Mi conclusión#
Un firewall doméstico bueno no es el que tiene más reglas. Es el que permite explicar cada regla sin hacer arqueología.
Casa con acceso a lo que usa. IoT limitado. Invitados fuera de todo. Laboratorio con libertad, pero con valla. Administración desde pocos sitios. Logs útiles. Excepciones con fecha. Backups de configuración. Y nombres escritos para una persona cansada, no para impresionar a nadie.
Eso no convierte la red en perfecta. La convierte en mantenible. En casa, eso ya es bastante victoria.