En este Tutorial 5 de CLHOME aprenderás a crear reglas de firewall entre VLANs en un SonicWall TZ670 con SonicOS 7. La guía está pensada para principiantes: empezaremos identificando las redes y los objetos, reutilizaremos servicios predeterminados y construiremos una política de ejemplo que permita solo las comunicaciones necesarias.
Seguridad: todos los nombres, direcciones y dispositivos de los ejemplos son ficticios. No copies reglas directamente a una red en producción. Guarda una copia de seguridad, prepara una vía de recuperación local y no cambies las reglas que mantienen tu acceso administrativo mientras sigues el tutorial.
Qué vamos a conseguir
- Crear objetos para identificar redes y dispositivos concretos.
- Localizar servicios que SonicOS ya incluye por defecto.
- Permitir que Home acceda a una impresora o TV solo mediante los servicios necesarios.
- Entender cómo limitar una comunicación entre Services y Manage.
- Mantener el acceso a Internet para IoT e invitados sin permitir acceso general a las redes internas.
- Comprobar las reglas con pruebas de conectividad y registros.
Paso 1. Comprende una regla de firewall
Una regla decide qué tráfico puede pasar de una zona a otra. Antes de crearla, responde cuatro preguntas: quién inicia la conexión, a qué destino quiere llegar, qué servicio necesita y si la acción debe ser Allow o Deny.
Por ejemplo, permitir que un ordenador doméstico imprima en una impresora concreta es más seguro que permitir cualquier comunicación entre toda la red Home y toda la red IoT. Las VLAN separan redes, pero las reglas del firewall determinan qué tráfico puede cruzar entre ellas.
Paso 2. Identifica las redes y las zonas
En SonicOS, abre NETWORK → System → Interfaces y comprueba qué interfaz y zona corresponden a cada red. Después entra en POLICY → Rules and Policies → Access Rules para ver las reglas que afectan a esas zonas.
No te guíes solo por el nombre de una VLAN. Elige las zonas que corresponden a las interfaces reales de origen y destino. Para este tutorial usaremos los nombres ficticios Home, Services, Manage, IoT e Guests.
Paso 3. Crea objetos de dirección
Los objetos de dirección permiten seleccionar una red o un equipo por su nombre. Así evitamos introducir una IP manualmente en cada regla y reducimos errores.
- Entra en OBJECT → Match Objects → Addresses.
- Pulsa Add para crear un objeto.
- Escribe un nombre descriptivo, por ejemplo
DEMO_PRINTER. - En tipo, selecciona Host si representa un único dispositivo o Network si representa una subred.
- Selecciona la zona correspondiente e introduce la dirección de ejemplo o la dirección verificada de tu propia instalación.
- Guarda y comprueba que el objeto aparece en la lista.
Para la impresora es preferible un objeto de tipo Host. Para identificar una red completa, utiliza un objeto Network. No crees duplicados si ya existe un objeto correcto.
Paso 4. Selecciona un servicio predeterminado
Entra en OBJECT → Match Objects → Services y busca el servicio que necesita la aplicación. En esta guía empezaremos con los servicios que SonicOS incluye por defecto; no necesitas crear servicios personalizados si ya existe uno que coincide con el protocolo y puerto necesarios.
No supongas que todas las impresoras o televisores utilizan los mismos puertos. Consulta la documentación del fabricante o la configuración del servicio concreto. HTTPS suele utilizar TCP 443, pero eso no significa que sea el único servicio que necesita una aplicación.
Si no encuentras el servicio necesario, identifica primero el protocolo y el puerto. Solo entonces crea un objeto de servicio personalizado, con el rango más reducido posible. No abras rangos amplios “por si acaso”.
Paso 5. Crea una regla de permiso específica
Ejemplo: permitir que un equipo doméstico utilice un servicio concreto de una impresora ficticia.
- Ve a POLICY → Rules and Policies → Access Rules.
- Selecciona la combinación de zonas de origen y destino adecuada para el tráfico.
- Añade una regla y escribe un nombre descriptivo, por ejemplo
DEMO_HOME_TO_PRINTER. - Selecciona la acción Allow.
- En el origen, selecciona el equipo o la red autorizada.
- En el destino, selecciona el objeto de la impresora, no toda la red IoT.
- En Port/Services, selecciona solo el servicio que hayas identificado y verificado.
- Revisa la regla completa y guarda únicamente cuando los campos sean correctos.
Si necesitas permitir un servicio de una TV, repite el mismo razonamiento con el objeto de destino y los servicios que realmente utiliza. No habilites toda la comunicación entre Home e IoT para facilitar el descubrimiento o el acceso multimedia.
Paso 6. Limita Services hacia Manage
Si una aplicación de Services necesita acceder a un dispositivo de administración, identifica el servidor de origen, el dispositivo de destino y el servicio exacto. Crea una regla limitada a esos objetos y al servicio necesario. No concedas acceso general entre ambas redes si basta con una excepción concreta.
Si no existe una necesidad documentada de esa comunicación, no crees la regla. Las excepciones deben responder a una necesidad real y revisarse cuando la aplicación deje de necesitarlas.
Paso 7. Mantén IoT e invitados aislados
IoT e invitados pueden necesitar acceso a Internet, pero eso no implica que deban acceder a servidores, ordenadores o interfaces de administración.
- Revisa las reglas desde la zona IoT hacia las zonas internas.
- Revisa las reglas desde la zona Guests hacia las zonas internas.
- Identifica cualquier permiso general que permita tráfico no deseado.
- Configura las denegaciones necesarias, respetando las excepciones legítimas y el comportamiento stateful del firewall.
- Comprueba que las reglas de salida a WAN permiten el acceso a Internet que necesita cada red.
- Prueba desde dispositivos conectados realmente a IoT e invitados: Internet debe funcionar y los recursos internos no autorizados deben seguir bloqueados.
La tabla final depende de las reglas que ya existan, de las zonas y de las necesidades de cada instalación. No copies una lista genérica de reglas sin comprobar qué tráfico coincide con ellas.
Paso 8. Cómo debería quedar la política
| Comunicación de ejemplo | Resultado deseado | Alcance |
|---|---|---|
| Home → impresora concreta | Permitir | Solo servicios necesarios |
| Home → TV concreta | Permitir | Solo servicios verificados |
| Services → equipo Manage autorizado | Permitir si existe necesidad | Origen, destino y servicio específicos |
| IoT → redes internas | Bloquear | Salvo excepciones justificadas |
| Guests → redes internas | Bloquear | Sin acceso general a redes privadas |
| IoT → Internet | Permitir según política | Solo la salida necesaria |
| Guests → Internet | Permitir según política | Sin acceso lateral a redes privadas |
Paso 9. Comprueba el orden y la coincidencia
Una regla puede no producir el resultado esperado si otra regla coincide con el tráfico o si has elegido una combinación de zonas incorrecta. En Access Rules, revisa la prioridad, el estado, los contadores y los registros disponibles. No muevas reglas de producción de forma experimental.
- Identifica el origen, el destino y el servicio de la conexión de prueba.
- Comprueba la zona de cada interfaz.
- Localiza la regla que debería coincidir y revisa sus contadores o registros.
- Verifica si otra regla más general está afectando al tráfico.
- Realiza un único cambio controlado y repite la prueba.
Paso 10. Pruebas finales
| Prueba | Resultado esperado |
|---|---|
| Equipo autorizado → servicio de impresora permitido | Funciona |
| Equipo no autorizado → servicio restringido | Bloqueado |
| Services → servicio de Manage autorizado | Funciona solo si la excepción existe |
| IoT → red interna no autorizada | Bloqueado |
| Invitados → recurso interno | Bloqueado |
| IoT → Internet | Funciona según la política de salida |
| Invitados → Internet | Funciona según la política de salida |
Si una prueba falla, no añadas permisos generales de inmediato. Comprueba las IP, las VLAN, las zonas, los objetos, el servicio y los registros. Si una modificación interrumpe la administración, utiliza el procedimiento de recuperación preparado antes de empezar.
Lista final de comprobación
- Los objetos representan las redes y dispositivos correctos.
- Los servicios predeterminados se han reutilizado cuando corresponden.
- Las reglas permiten solo el origen, destino y servicio necesarios.
- IoT e invitados no pueden acceder a redes internas sin autorización.
- La salida a Internet funciona según lo previsto.
- Se han probado tanto las comunicaciones permitidas como las bloqueadas.
- La administración del firewall sigue funcionando y los cambios están documentados.
Conclusión: una red segura no necesita permitir que todo se comunique con todo. Necesita reglas comprensibles, excepciones justificadas y pruebas que demuestren que la política funciona. En el siguiente tutorial profundizaremos en el aislamiento de IoT e invitados sin perder los servicios que sí necesitamos.
Siguiente tutorial: aislamiento de IoT e invitados
En el tutorial 6 continuaremos la serie con el aislamiento de las redes IoT e invitados, manteniendo la conectividad necesaria sin permitir el acceso general a la red doméstica.