Configurar y probar VLAN en Sophos Firewall

Una VLAN en Sophos Firewall es más que una ID de VLAN. Para que la nueva red realmente funcione, la interfaz principal, el etiquetado del conmutador, la zona, la dirección IP, DHCP, DNS, Device Access, las reglas del firewall y NAT deben encajar.

El artículo describe el flujo genérico del firewall de Sophos y las decisiones operativas clave en torno a la segmentación, la zona, DHCP, las reglas y las pruebas. Cuando se trata de una implementación concreta con conmutadores UniFi, el artículo Configure VLAN en Sophos Firewall y UniFi Switch es adecuado. Para casos de puentes especiales después de SFOS 22, Sophos Firewall Verifique las VLAN del puente según SFOS 22 es el mejor comienzo.

Respuesta corta

Se crea una VLAN en Sophos Firewall en Network > Interfaces > Add interface > Add VLAN. Después de eso normalmente necesitarás:

• una zona adecuada
• una dirección IP estática como puerta de enlace
• Servidor DHCP o retransmisión DHCP
• Diseño DNS
• Device Access para servicios de firewall locales
• Reglas de firewall para Internet, redes internas o servidores.
• Registro y una breve prueba de aceptación.

Solo cuando un cliente de prueba muestra la dirección IP, la puerta de enlace, el DNS, las conexiones permitidas, las conexiones bloqueadas y las entradas de registro apropiadas, la VLAN está limpia.

Cuándo tiene sentido una VLAN

Las VLAN separan lógicamente redes de Layer 2. En Sophos Firewall se usan a menudo para transportar varias redes por el mismo uplink físico o por un LAG.

Aplicaciones típicas:

• Red de cliente y red de servidor separadas
• Aislar el WiFi de invitados de la LAN interna
• Colocar teléfonos VoIP en su propia red.
• Limitar IoT, cámaras o impresoras
• Crear una red de administración para PC de administración, conmutadores y monitoreo.
• Ejecute DMZ o red de servidor a través de un enlace ascendente de conmutador común

Sin embargo, una VLAN no reemplaza las reglas del firewall. Garantiza la separación técnica en la Capa 2. Luego, Sophos Firewall decide si se permite el tráfico entre VLAN a través de zonas, enrutamiento, reglas de firewall, NAT y políticas de seguridad.

Una VLAN puede extenderse por varios switches. El tráfico entre dispositivos de la misma VLAN se transporta a través de los switches dentro de esa red de capa 2 y normalmente no pasa por la puerta de enlace de la VLAN. Por tanto, aunque Sophos Firewall sea la puerta de enlace predeterminada, no inspecciona automáticamente las comunicaciones dentro de la misma VLAN. El tráfico entre VLAN distintas necesita una ruta de capa 3 a través de un router, un switch de capa 3 o un firewall.

Planificar la arquitectura VLAN

La pregunta más importante no es cómo crear una VLAN. La pregunta más importante es qué áreas de seguridad debería haber en la red. Surgen muchos problemas porque las VLAN se crean de forma puramente técnica: VLAN 10, VLAN 20, VLAN 30. Después de unos meses, nadie sabe qué comunicación debería permitirse y por qué se desconectaron determinadas redes.

Conviene planificar las VLAN primero en función del riesgo, la función y la responsabilidad operativa. Una buena estructura inicial suele verse así:

• Gestión: Admin PCs, switchs, Access Points, monitoreo y controladores. El acceso a las interfaces administrativas debería estar estrictamente controlado.
• Clientes: Dispositivos de estaciones de trabajo, portátiles y dispositivos de usuario normal. Suele ser la red estándar con acceso a Internet y aprobaciones internas específicas.
• Servidor: Controlador de dominio, servidor de archivos y servidor de aplicaciones. No se debe poder acceder directamente a los servidores desde todas las redes de clientes.
• Invitados: WiFi para invitados y dispositivos externos. Esta red normalmente solo necesita Internet y no acceso a los sistemas internos.
• IoT y cámaras: Cámaras, impresoras, sensores y tecnología de construcción. Muchos de estos dispositivos tienen modelos de seguridad y actualización débiles.
• VoIP: Teléfonos, PBX y SBC. Las opciones propias de DHCP, QoS y una accesibilidad clara suelen ser útiles en este caso.
• Copia de seguridad: Servidores de respaldo, repositorios y almacenamiento inmutable. La separación protege contra ransomware y movimiento lateral.
• DMZ: Sistemas de acceso público o proxies inversos. Los servicios expuestos pertenecen a un área separada.

Este no es un esquema rígido. Una oficina pequeña no necesita necesariamente diez VLAN. Sin embargo, un entorno con múltiples ubicaciones, servidores, WLAN, cámaras, sistemas de respaldo y acceso externo no debería poner todo en una gran LAN.

Clasificar la microsegmentación de manera realista

La microsegmentación no significa que cada dispositivo necesite su propia VLAN. En la práctica, el mejor comienzo suele ser una segmentación macro limpia: los clientes, servidores, administración, invitados, IoT, respaldo y DMZ están separados. De este modo, los sistemas especialmente críticos se pueden segmentar con mayor precisión.

Ejemplos de segmentación más fina:

• Coloque el controlador de dominio en su propia subred de servidor.
• Hacer que los sistemas de respaldo solo sean accesibles desde unas pocas fuentes.
• Permitir la red de cámaras solo para NVR o VMS.
• Hacer que las impresoras solo sean accesibles a través de servidores de impresión o redes de clientes definidas.
• VLAN de administración abierta solo para dispositivos de administración y monitoreo.

Lo importante es que cada separación adicional también genera costos operativos. Necesita reglas, registros, pruebas, documentación y alguien que mantenga las excepciones. Una buena segmentación no es lo más complicada posible, sino más bien comprensible y verificable.

Preparación para ZTNA y acceso moderno

Una estructura VLAN limpia también ayuda más adelante con ZTNA, VPN, SASE u otros conceptos de acceso. Si las aplicaciones internas ya están ubicadas en redes claras de servidores o aplicaciones, el acceso se puede publicar de forma más específica y no es necesario liberar una LAN plana completa.

Lo siguiente es particularmente útil para ZTNA:

• Los servidores de aplicaciones se encuentran en redes de servidores conocidas.
• El acceso de administración está separado del tráfico normal de clientes.
• Los nombres DNS y las rutas internas están claramente documentados.
• Las reglas de firewall muestran qué usuarios o grupos de ubicación requieren qué objetivos.
• Se desmontarán las mantas antiguas LAN to LAN o las reglas Any to Any.

Si utiliza Sophos ZTNA más adelante, podrá acceder a él a través de Planificar y crear Sophos ZTNA Gateway. La planificación de VLAN no es un requisito obligatorio para esto, pero hace que el funcionamiento posterior sea mucho más limpio.

¿Cuántas VLAN se necesitan?

No existe un número correcto fijo. Debe crear VLAN donde sea necesaria su propia decisión de seguridad.

Tener su propia VLAN generalmente tiene sentido si se aplica al menos uno de estos puntos:

• La red necesita diferentes reglas de firewall. Entonces deberías planificar tu propia zona o al menos tu propio objeto VLAN.
• Device Access debería verse diferente. Una zona separada suele estar más limpia.
• Las opciones de DHCP difieren, por ejemplo, para VoIP, PXE o redes de invitados.
• El tráfico debe registrarse, monitorearse o evaluarse por separado.
• Los dispositivos tienen un riesgo significativamente diferente, por ejemplo IoT, invitados, respaldo o administración.
• Existen otros responsables o su propio proceso operativo.

Pero no debe forzar inmediatamente cada pequeño tema especial a una nueva VLAN. Si dos redes de clientes obtienen exactamente las mismas reglas, la misma política web y el mismo Device Access, una zona común con objetos de red claros puede ser suficiente.

Planifique con anticipación

Antes de crear, se debe documentar brevemente la VLAN. No es necesario que sea un gran plan de red, pero los valores más importantes deben quedar claros.

A menudo basta con un conjunto de planificación compacto:

• Nombre de VLAN: por ejemplo Clients
• ID de VLAN: por ejemplo 100
• Subred: por ejemplo 10.100.0.0/24
• Puerta de enlace en Sophos Firewall: por ejemplo 10.100.0.1
• Interfaz principal: por ejemplo Port3 o LAG1
• Zona: por ejemplo Client, LAN, Guest, Server o DMZ
• DHCP: Sophos Firewall, retransmisión DHCP o servidor externo
• DNS: Firewall, servidores DNS internos o diseño intencionalmente diferente
• Propósito: por ejemplo, clientes de estaciones de trabajo con acceso a Internet

La zona es particularmente importante. Esta configuración afecta posteriormente a las reglas de firewall, Device Access, políticas web, IPS, registros y solución de problemas. Sophos Firewall Configurar zonas e interfaces es adecuado para la planificación básica de zonas.

La VLAN ID debe estar en el rango válido de 1 a 4094. La misma VLAN ID no puede añadirse más de una vez en el mismo parent interface físico. En redes productivas, la ID no solo debe asignarse técnicamente, sino nombrarse de forma coherente con la configuración del switch, SSID Wi-Fi, ámbito DHCP, documentación y monitorización. Si VLAN 100 se llama Clients en el firewall, Office en el switch y LAN-neu en DHCP, el troubleshooting resulta innecesariamente difícil.

En una XGS Appliance, Sophos no establece un máximo fijo de interfaces VLAN por interfaz física. Eso no convierte un trunk ilimitado en un buen diseño. Sophos recomienda repartir muchas VLAN entre varias interfaces para mejorar el rendimiento y la administración. Hay que valorar la carga, el modelo, la redundancia y si el recorrido sigue siendo comprensible durante una avería.

Entender Parent Interface y switch tagging

La Interfaz principal es el puerto físico, puente o LAG en el que Sophos Firewall recibe los paquetes VLAN etiquetados. La ID de VLAN en Sophos Firewall debe coincidir exactamente con lo que envía el conmutador en este enlace.

Diseños típicos:

• Puerto físico como troncal: Un enlace ascendente de switch transporta múltiples VLAN etiquetadas al firewall.
• LAG como troncal: Varios puertos físicos forman un LAG, en el que hay varias interfaces VLAN.
• Interfaz RED: Las VLAN a través de una SD-RED 60 requieren Standard/Unified y modos de puerto LAN compatibles. Elegir el modo de funcionamiento correcto de Sophos RED explica los límites.
• Puerto de acceso sin etiqueta VLAN: ​​Un dispositivo final cuelga sin etiquetar en una VLAN. El etiquetado ocurre en el conmutador, no en el cliente.
• Puente con VLANs: Caso especial que se debe revisar con atención, especialmente para migraciones o diseños transparentes.

Si una PC cliente normal está conectada directamente a un puerto de conmutador, normalmente envía sin etiquetar. Luego, el conmutador asigna este puerto a una VLAN. El Sophos Firewall solo ve la VLAN en el enlace ascendente cuando el conmutador transporta la VLAN etiquetada al firewall.

¿Puertos individuales o VLAN trunk mediante LAG?

En teoría, puede utilizar su propio puerto de firewall físico por VLAN. Esto es comprensible para instalaciones muy pequeñas, pero no se escala correctamente. Los puertos se vuelven escasos, el cableado se vuelve confuso y los cambios de zonas, conmutadores o HA se vuelven más tediosos más adelante.

En entornos productivos, un diseño de trunk suele ser más claro:

1. El Sophos Firewall está conectado a uno o más conmutadores centrales.
2. Un puerto físico o LAG transporta múltiples VLAN etiquetadas.
3. En el firewall, se crean interfaces VLAN separadas para cada VLAN en esta interfaz principal.
4. El firewall sigue siendo la puerta de enlace predeterminada para las VLAN y decide las políticas de enrutamiento y seguridad.

Nuestra variante preferida suele ser un LAG con dos enlaces ascendentes rápidos, por ejemplo 2x SFP+, siempre que el firewall y los conmutadores lo admitan. Luego, las VLAN se ejecutan en él como interfaces etiquetadas. Esto no significa automáticamente el doble de velocidad para una sola sesión, pero sí proporciona más redundancia, más reservas y un diseño más claro que muchos puertos de cobre individuales por VLAN.

Las variantes más importantes:

• Un puerto de firewall por VLAN: ​​​​fácil de entender y se puede implementar con pocos conocimientos de VLAN. Pero no escala bien, requiere muchos puertos y rápidamente hace que el cableado sea confuso.
• Un puerto troncal con VLANs: sencillo, limpio y con pocos cables. Sin embargo, el enlace ascendente individual sigue siendo un único punto de falla.
• LAG con troncal VLAN: ​​redundante, limpio y fácilmente escalable. El conmutador y el firewall deben admitir correctamente LAG o LACP.
• Enrutamiento en conmutador central: muy eficaz en redes grandes. Sin embargo, el firewall ya no ve completamente el tráfico interno de este a oeste.

Para muchas redes PYME y medianas, el firewall como puerta de enlace predeterminada para las VLAN es la mejor decisión de seguridad. Luego, el tráfico interno entre VLAN se ejecuta a través de Sophos Firewall y se puede controlar con reglas de firewall, IPS, políticas web, registros y funciones de seguridad posteriores. El enrutamiento en el conmutador central puede resultar útil si se requiere un rendimiento interno este-oeste muy alto. Pero luego hay que aceptar conscientemente que el firewall ya no ve todas las comunicaciones internas.

Como regla general:

• Orientado a la seguridad y claro: Puertas de enlace VLAN en Sophos Firewall.
• Rendimiento interno muy alto: Verifique el enrutamiento en el conmutador central, pero agregue zonas de seguridad y ACL de manera limpia.
• Nuevas instalaciones: Enruta las VLAN al firewall vía troncal o LAG, no desperdicies ni un solo puerto por VLAN.
• Sitios pequeños: Un solo puerto troncal puede ser suficiente si no se requiere redundancia.

Conceptos erróneos comunes:

• La VLAN se crea en el firewall, pero el enlace ascendente del switch no la transporta.
• La VLAN está etiquetada en el puerto de acceso, aunque el cliente espera que no esté etiquetada.
• La ID de VLAN no coincide en el conmutador y el firewall.
• La VLAN se creó en la interfaz principal incorrecta.
• La interfaz principal se operó como un puerto de acceso normal en lugar de un troncal.
• Ya se creó una VLAN en el Parent Interface y después se quiere cambiar espontáneamente el puerto físico a DHCP o PPPoE. Estos cambios deben planificarse antes, porque Sophos no permite cambiar arbitrariamente a DHCP o PPPoE la asignación IP de un interface físico estático después de configurar VLANs.

Crear interfaz VLAN

Ruta del menú:

Network > Interfaces > Add interface > Add VLAN

Procedimiento:

1. Introduzca un Name de hasta 58 caracteres, por ejemplo Clients VLAN 100. Puede cambiarse más adelante y aparece en otros ajustes.
2. Seleccione la interfaz principal como Interfaz, por ejemplo Port3 o LAG1.
3. Seleccione Zone de forma deliberada.
4. Ingrese ID de VLAN, por ejemplo 100.
5. En IPv4 configuration normalmente se utiliza Static.
6. Ingrese la dirección IP y la máscara de subred, por ejemplo 10.100.0.1/24.
7. Guardar.

Para las VLAN internas, la IP del firewall suele ser la puerta de enlace predeterminada de los clientes. Si otro sistema está enrutando o el firewall solo ve ciertas redes, este diseño debe documentarse explícitamente. De lo contrario, buscará reglas de firewall más adelante, aunque el cliente no esté usando Sophos Firewall como puerta de enlace.

Después de guardar, conviene desplegar el Parent Interface en Network > Interfaces o usar el filtro VLAN. Sophos muestra interfaces VLAN debajo del Parent Interface y también en la vista VLAN. El nombre de hardware generado automáticamente se basa en Parent Interface y VLAN ID; para la operación importa sobre todo un nombre de interface claro, porque aparece en ajustes, logs y reglas.

Para modificar una VLAN existente, abra Network > Interfaces > VLAN, el menú de esa VLAN y seleccione Edit interface. Guarde los cambios con Save y vuelva a comprobar las conexiones afectadas. Antes de cambiar la puerta de enlace, la zona o la interfaz principal, asegúrese de disponer de una vía de acceso administrativo independiente.

Asignación IPv4 para VLAN internas y WAN

Static es casi siempre la opción adecuada para una VLAN interna, porque los clientes necesitan una puerta de enlace estable. Al seleccionar la zona WAN, SFOS también solicita Gateway name y, con asignación estática, Gateway IP address.

Una VLAN WAN puede usar DHCP o PPPoE en IPv4 configuration. Con DHCP, SFOS muestra la dirección, máscara y puerta de enlace entregadas por el proveedor. PPPoE requiere al menos Username y Password. Preferred IP solo expresa una preferencia; el servidor puede asignar otra dirección. Configure Access concentrator/service name únicamente si lo exige el proveedor.

Cambie LCP echo interval o LCP failure solo si las mediciones o los requisitos del proveedor lo justifican. Desmarcar la casilla no desactiva LCP, sino que restaura 20 segundos y 3 solicitudes sin respuesta. Programe Schedule time for reconnect en una ventana de mantenimiento, ya que el proveedor puede asignar una dirección dinámica tras reconectar. Después compruebe puerta de enlace, dirección pública, DNS, NAT y una conexión real a Internet.

Con PPPoE, IPv4/netmask muestra la dirección IPv4 y la máscara asignadas por el proveedor; Gateway IP address muestra la IP de la puerta de enlace configurada. Son campos de visualización, no de entrada estática. Access concentrator/service name limita las conexiones a los concentradores de acceso que pueden ofrecer el servicio indicado. LCP echo interval establece el intervalo entre las solicitudes de eco que comprueban el enlace. Si las solicitudes especificadas en LCP failure quedan sin respuesta, SFOS desconecta la conexión PPPoE. Ante desconexiones inesperadas, compruebe primero el enlace y el proveedor en lugar de aumentar simplemente el umbral.

IPv6, delegación de prefijos y Router Advertisement

En IPv6 configuration se puede elegir entre Static, DHCP y Delegated. Una VLAN WAN puede obtener su dirección IPv6 mediante DHCPv6. En el modo Auto, SFOS selecciona el método; en Manual se distingue entre DHCP only y Stateless. Con Stateless, la configuración de la dirección sigue los indicadores M y O de los router advertisements recibidos; Accept other configuration from DHCP permite obtener valores adicionales, como DNS, mediante DHCPv6.

Para Static en IPv6 configuration, introduzca la dirección IPv6 y el prefijo previstos en IPv6/prefix. Si Zone es WAN, introduzca también Gateway name y la dirección IPv6 de la puerta de enlace en Gateway IP address. La dirección, el prefijo y la puerta de enlace deben ajustarse al plan del proveedor o de la red.

Para distribuir un prefijo del proveedor se activa DHCP prefix delegation en la VLAN WAN. Preferred delegated prefix admite las longitudes /48, /52, /56 o /60; aun así, el proveedor puede delegar otro prefijo. DHCP rapid commit solo acorta el intercambio si el servidor DHCPv6 también admite Rapid Commit.

La dirección del prefijo en Preferred delegated prefix es opcional: puede dejarla vacía e indicar una de las longitudes admitidas. Para DHCP rapid commit, no basta con que el servidor lo admita; Rapid Commit también debe estar activado en el servidor DHCPv6. Con asignación IPv6 DHCP, la zona WAN requiere además Gateway name; Gateway IP muestra la dirección IPv6 de la puerta de enlace configurada.

La VLAN interna utiliza después Delegated y la interfaz WAN preparada como Upstream interface. SFOS deriva de ella la dirección IPv6 y la subred de la VLAN. Router advertisement proporciona la información de direccionamiento a los clientes; el DHCPv6 server opcional entrega parámetros adicionales como DNS, pero en este modo no asigna direcciones IPv6. Configurar la delegación de prefijos IPv6 en Sophos Firewall explica el flujo completo del proveedor y las subredes; Router Advertisement IPv6 en Sophos Firewall cubre el lado del cliente.

En modo Delegated, IPv6 address muestra la dirección asignada, incluido el prefijo delegado, el Subnet ID, el Interface ID y la longitud del prefijo. Esta composición permite comprobar si la VLAN usa el prefijo y la subred previstos. Si esa interfaz se asigna a la zona WAN, introduzca también Gateway name y la dirección IPv6 de la puerta de enlace en Gateway IP; una VLAN interna habitual no utiliza esa rama de entrada WAN.

En una VLAN con DHCPv6, DAD attempts limita los intentos de Duplicate Address Detection. En Allowed RA servers solo se permiten las fuentes de router advertisements esperadas mediante su dirección MAC o IPv6. Ambos valores forman parte de la topología IPv6 documentada y no deben modificarse por tanteo ni abrirse de forma general.

Aquí, DAD attempts cuenta los mensajes Neighbor Solicitation consecutivos enviados para realizar Duplicate Address Detection sobre una dirección provisional, no los intentos de conexión al proveedor.

Para reglas de firewall debería crearse además un objeto de red adecuado:

Hosts and services > IP host

Ejemplo:

• Name: NET_Client_VLAN100
• IP version: IPv4
• Type: Network
• IP address: 10.100.0.0
• Subnet: /24

Estos objetos hacen que reglas, búsquedas en logs y revisiones posteriores sean mucho más claros que rangos IP escritos directamente en cada regla.

Configurar DHCP y DNS

Después de la interfaz VLAN, se necesita una decisión para asignar direcciones.

• DHCP en Sophos Firewall: adecuado para sitios simples, clientes, invitados, IoT o redes VoIP.
• DHCP Relay: útil para un servidor DHCP central de Windows o una infraestructura DHCP existente.
• Servidor DHCP externo en la VLAN: ​​Caso especial cuando un servidor es responsable directamente en la VLAN.
• IP estáticas: adecuadas para servidores pequeños, redes de administración o infraestructura.

La planificación y las pruebas del rango, la puerta de enlace, DNS, el tiempo de concesión y las asignaciones estáticas se explican en Configurar Sophos Firewall como servidor DHCP. Las opciones especiales como PXE, VoIP o los valores específicos del fabricante se describen en Configurar opciones DHCP en Sophos Firewall.

Sophos Firewall puede configurar DHCP server y DHCP relay en interfaces físicas y virtuales como VLANs, Wireless Networks y Bridges. En Alias interfaces no es el lugar correcto. Si se planifica DHCP a través de enlaces VPN, también hay que comprobar si el diseño VPN concreto soporta DHCP Relay; en VPN route-based no está dado automáticamente.

Al diseñar DNS, debe decidir claramente si los clientes utilizan Sophos Firewall como reenviadores de DNS o solicitan directamente a los servidores DNS internos. Cuando el firewall actúa como reenviador de DNS, los dominios internos a menudo deben reenviarse a los servidores DNS correctos a través de Rutas de solicitud de DNS en Sophos Firewall.

Comprobar Device Access

Device Access controla los servicios locales de Sophos Firewall. Esto no es lo mismo que una regla de firewall entre VLAN.

Ejemplos típicos:

• Los clientes deben utilizar el firewall como servidor DNS: permitir DNS para la zona.
• La solución de problemas debería permitir hacer ping en el firewall: habilite conscientemente Ping/Ping6.
• Las VLAN normales de cliente, invitado o IoT no deben tener acceso WebAdmin o SSH.
• El acceso de administración debe realizarse a través de una red de administración dedicada o Local Service ACL Exception Rules.

El procedimiento exacto está en Sophos Firewall Acceso seguro: Configurar Device Access correctamente.

Agregar reglas de firewall y NAT

Una nueva VLAN necesita entonces reglas de firewall adecuadas. Sin una regla, un cliente puede obtener una dirección IP, pero no automáticamente en Internet u otras redes internas.

Cree una regla nueva en Rules and policies > Add firewall rule > New firewall rule. Introduzca las zonas de origen y destino, los objetos de red y los servicios del plan de VLAN y guarde con Save.

Las reglas de firewall específicas de una VLAN también pueden exigir autenticación de usuarios. El acceso depende entonces no solo de la red y la zona de origen, sino también del usuario autenticado o de su grupo. Una VLAN por sí sola no autentica usuarios; configure la autenticación adecuada y compruébela con un usuario de prueba autorizado y otro no autorizado.

Una primera regla sencilla de Internet podría verse así:

• Nombre de la regla: Clients_to_WAN
• Zonas de origen: Client o LAN
• Redes de origen: Red VLAN, por ejemplo 10.100.0.0/24
• Zonas de destino: WAN
• Redes de destino: Any
• Servicios: servicios requeridos conscientemente, no automáticamente Any
• Log firewall traffic: activado

Se deben crear reglas separadas para el acceso interno. No se debe permitir que una VLAN de invitados, IoT o cámaras acceda de forma general a redes de servidores o de gestión. La planificación de reglas se describe con más detalle en Comprender y configurar de forma segura las reglas de Sophos Firewall.

El ejemplo oficial coloca ambas redes VLAN como origen y destino de una sola regla de LAN a LAN. Funciona en un laboratorio, pero suele ser demasiado amplio para producción. Es preferible crear reglas direccionales como Clients_to_Server_HTTPS, desde NET_Client_VLAN100 hacia un único objeto de servidor y solo con HTTPS. Añada la regla inversa únicamente si los sistemas de la red de servidores deben iniciar conexiones hacia los clientes. Así, los registros muestran con claridad la dirección prevista.

NAT no es necesaria para todo el tráfico VLAN. Para el acceso normal a Internet, se suele utilizar la regla MASQ o SNAT existente. La NAT suele ser incorrecta entre las VLAN internas porque los sistemas de destino ya no ven la IP real del cliente. La clasificación está en Comprensión de NAT en Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Prueba de aceptación

Una VLAN no está completa hasta que se prueba el flujo de paquetes. Un solo ping no es suficiente.

Procedimiento de prueba útil:

1. Conecte el cliente de prueba al puerto del switch o SSID deseado.
2. Verifique si el cliente recibe una dirección IP de la VLAN correcta.
3. Verifique la puerta de enlace, el servidor DNS y el dominio de búsqueda.
4. Haga ping a la IP del firewall en la VLAN si el ping está permitido.
5. Pruebe la resolución de DNS para nombres internos y externos.
6. Pruebe el acceso a Internet permitido.
7. Pruebe el acceso interno permitido, si se proporciona.
8. Pruebe el acceso interno no permitido intencionalmente y verifique el bloqueo en Log Viewer.
9. En Log Viewer comprobar Rule ID, Source zone, Destination zone y NAT ID.
10. Si algo no queda claro, usar Packet capture en la interfaz VLAN.

Sophos Firewall Regla de prueba con Log Viewer, Policy Test y Packet Capture es adecuado para la evaluación con Log Viewer, Policy Test y Packet Capture.

Errores típicos

• VLAN no permitida en el enlace ascendente del conmutador: El cliente no obtiene una dirección IP o no llega a la puerta de enlace. Verifique la troncal o la VLAN etiquetada en el conmutador.
• VLAN ID ya existente en el mismo parent interface: Sophos Firewall no permite la misma VLAN ID dos veces en la misma interfaz física. Revisar las interfaces VLAN existentes en lugar de crear un duplicado.
• Interfaz principal incorrecta: El firewall no ve el tráfico. Compare la interfaz VLAN y el cableado físico.
• Puerto del cliente etiquetado en lugar de sin etiquetar: Los clientes normales no terminan en la VLAN. Verifique el puerto de acceso o el perfil de VLAN nativo.
• Falta DHCP o respuestas DHCP incorrectas: El cliente no recibe una dirección IP o recibe una dirección IP incorrecta. Verifique las concesiones de DHCP y Packet Capture para UDP 67/68.
• No hay un objeto IP host para la VLAN: Las reglas contienen redes sin objeto o un objeto incorrecto. Crear correctamente el IP host en Hosts and services y utilizarlo en las reglas.
• Falta DNS Device Access: El tráfico IP funciona, pero la resolución de nombres no. Device Access y verifique el DNS del cliente.
• Zona incorrecta seleccionada: Las reglas o políticas no se aplican como se esperaba. Compare las reglas de zona de interfaz y firewall.
• Falta la regla de firewall: El cliente tiene una dirección IP, pero el tráfico está bloqueado. Consulte Log Viewer y Rule ID.
• NAT entre VLAN internas: Los sistemas de destino ven una IP de origen incorrecta. Verifique las reglas de NAT y planifique excepciones de NAT internas.

Si una regla no coincide, el problema suele estar relacionado con Zone, Source Network, Gateway o switch tagging. El artículo Sophos Firewall La regla no aplica: verificar causas ayuda con la distinción.

Revertir el cambio

No elimine la interfaz VLAN como primer paso de diagnóstico. Restaure antes la asignación anterior del puerto o SSID y compruebe qué configuraciones DHCP, reglas, reglas NAT, rutas y objetos usan la VLAN. De este modo, la última configuración funcional sigue accesible. Antes de eliminarla, verifique un acceso administrativo independiente y quite cada dependencia o asígnela a otra interfaz.

Tras una migración controlada, abra Network > Interfaces > VLAN, el menú de la interfaz y seleccione Delete interface. Confirme después que esa VLAN ya no es necesaria en el trunk y que ningún cliente recibe direcciones de la subred. Ante un despliegue fallido suele bastar con restaurar el puerto o SSID, desactivar las reglas nuevas y conservar la interfaz hasta encontrar la causa.

Verificación operativa

Para las VLAN productivas, no sólo la configuración inicial debe ser correcta. Es fundamental que los administradores posteriores puedan comprender por qué existe la VLAN y qué reglas le pertenecen.

Debes documentar:

• ID de VLAN, nombre y subred
• Interfaz principal y enlace ascendente de conmutación
• nombre de hardware generado automáticamente y nombre de interface descriptivo
• Zona y finalidad de seguridad.
• objeto IP host para reglas de firewall
• Fuente DHCP y servidor DNS
• zonas objetivo y servicios permitidos
• decisión NAT
• propietario responsable
• Cliente de prueba o procedimiento de prueba.
• Fecha de la última verificación de reglas

Para entornos más grandes, también vale la pena una matriz de acceso simple. Esta matriz muestra qué VLAN pueden comunicarse entre sí y cuáles se mantienen deliberadamente separadas.

Una matriz de acceso simple puede verse así:

• Clientes a Internet: permitidos con Política Web, DNS Protection y registro.
• Clientes a servidor: solo puertos de aplicación definidos.
• Invitados al interno: bloqueado.
• IoT a Internet: solo destinos y puertos requeridos.
• IoT al servidor: solo a NVR, servidor de impresión o sistemas de gestión.
• Administración hacia infraestructura: permitido para protocolos de administración.
• Copia de seguridad en el servidor: permitida específicamente, lo que limita severamente la dirección inversa.

Esta matriz suele ser más importante que la propia lista de VLAN. Esto evita que posteriormente se creen reglas generales que realmente anulen la segmentación.

Preguntas frecuentes