# Tutorial 5: Crear reglas de firewall entre VLANs en SonicWall TZ670

- Link: https://www.clhome.net/crear-reglas-de-firewall-entre-vlans-en-sonicwall/
- Published: 2026-10-12T13:15:41+02:00
- Author: gerard

Ruta de aprendizaje / 5 de 9

[1](https://www.clhome.net/disenar-red-homelab-vlans-sonicwall-unifi/)[2](https://www.clhome.net/configurar-vlans-sonicwall-tz670/)
[3](https://www.clhome.net/configurar-un-switch-unifi-con-vlans-y-puertos-trunk-access/)
[4](https://www.clhome.net/configurar-redes-wi-fi-unifi-asociadas-a-vlans/)5[6](https://www.clhome.net/aislar-iot-invitados-sonicwall-unifi/)
[7](https://www.clhome.net/permitir-impresion-chromecast-y-mdns-entre-vlans-de-forma-segura-3/)
[8](https://www.clhome.net/diagnosticar-problemas-de-vlan-dhcp-y-conectividad/)[9](https://www.clhome.net/preparar-un-acceso-de-recuperacion-para-el-firewall/)

[← Anterior](https://www.clhome.net/configurar-redes-wi-fi-unifi-asociadas-a-vlans/)
[Índice de guías](https://www.clhome.net/guias/)[Siguiente →](https://www.clhome.net/aislar-iot-invitados-sonicwall-unifi/)

![Infografía resumen del tutorial 5 de CLHOME sobre reglas de firewall entre VLANs,
aislamiento de IoT e invitados y comprobación de conectividad.](https://www.clhome.
net/wp-content/uploads/2026/10/clhome-tutorial-5-firewall-vlans-sonicwall.png)

Resumen visual: objetos de red, servicios, reglas de acceso y pruebas de seguridad.

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.

 1. Entra en **OBJECT → Match Objects → Addresses**.
 2. Pulsa **Add** para crear un objeto.
 3. Escribe un nombre descriptivo, por ejemplo `DEMO_PRINTER`.
 4. En tipo, selecciona **Host** si representa un único dispositivo o **Network** si
    representa una subred.
 5. Selecciona la zona correspondiente e introduce la dirección de ejemplo o la dirección
    verificada de tu propia instalación.
 6. 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.

 1. Ve a **POLICY → Rules and Policies → Access Rules**.
 2. Selecciona la combinación de zonas de origen y destino adecuada para el tráfico.
 3. Añade una regla y escribe un nombre descriptivo, por ejemplo `DEMO_HOME_TO_PRINTER`.
 4. Selecciona la acción **Allow**.
 5. En el origen, selecciona el equipo o la red autorizada.
 6. En el destino, selecciona el objeto de la impresora, no toda la red IoT.
 7. En **Port/Services**, selecciona solo el servicio que hayas identificado y verificado.
 8. 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.

 1. Revisa las reglas desde la zona IoT hacia las zonas internas.
 2. Revisa las reglas desde la zona Guests hacia las zonas internas.
 3. Identifica cualquier permiso general que permita tráfico no deseado.
 4. Configura las denegaciones necesarias, respetando las excepciones legítimas y el
    comportamiento stateful del firewall.
 5. Comprueba que las reglas de salida a WAN permiten el acceso a Internet que necesita
    cada red.
 6. 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.

 1. Identifica el origen, el destino y el servicio de la conexión de prueba.
 2. Comprueba la zona de cada interfaz.
 3. Localiza la regla que debería coincidir y revisa sus contadores o registros.
 4. Verifica si otra regla más general está afectando al tráfico.
 5. 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.

[Pasa al siguiente tutorial](https://www.clhome.net/aislar-iot-invitados-sonicwall-unifi/)