Sophos Firewall Verifique las VLAN del puente para SFOS 22

Las interfaces de puente en Sophos Firewall son prácticas si se va a continuar de forma transparente una red de Capa 2 existente o si se va a implementar una migración sin cambios IP inmediatos. Sin embargo, con las VLAN en un puente, el diseño rápidamente se vuelve propenso a errores: luego hay reenvío entre redes, tráfico al propio firewall, Device Access, DNS, AD, autenticación y, a menudo, configuraciones CLI antiguas.

Exactamente en este punto hay un caso operativo importante con SFOS 22. Sophos enumera un problema en la lista actual de problemas conocidos donde interfaces de puente con configuraciones de etiquetas VLAN CLI en SFOS 22.0 GA y SFOS 22.0 MR1 no procesan correctamente el tráfico etiquetado con VLAN si este tráfico se origina en el propio Sophos Firewall o termina en el firewall. Por ejemplo, esto puede afectar a Active Directory, DNS, Device Access, STAS, LDAP, RADIUS o al acceso de administración, aunque el tráfico normal se enrute a través del puente.

Sophos también describe ahora el legacy CLI VLAN tagging como deprecated. Estas configuraciones heredadas pueden impedir actualizaciones a SFOS 22.0 MR2 y versiones posteriores. Por eso esta revisión no es solo troubleshooting después de una actualización, sino también una preparación útil antes de la siguiente ventana de mantenimiento.

Este artículo no es un capítulo general de VLAN fundamentos. Para planificar zonas, interfaces, VLAN, puentes y LAG, Sophos Firewall Configurar zonas e interfaces encaja primero. Se trata específicamente del caso especial del puente VLAN después de SFOS 22.

Cuando este tema es relevante

La verificación tiene sentido cuando confluyen varios puntos:

El firewall se ejecuta en SFOS 22.0 GA o SFOS 22.0 MR1.
Hay una interfaz puente, por ejemplo br0.
Las VLAN históricamente se creaban usando la configuración de etiquetas CLI VLAN como system vlan-tag o se tomaban de una configuración anterior.
Los propios servicios de firewall deben alcanzar un VLAN etiquetado.
Después de una actualización, AD, DNS, autenticación, monitoreo o acceso de administración solo funcionan parcialmente.
El tráfico normal de clientes a través del puente parece seguir funcionando.
Se planifica una actualización a SFOS 22.0 MR2 o posterior, o está bloqueada por legacy CLI VLAN tagging.

El último punto es importante: si el puente continúa reenviando tráfico entre redes, el problema inicialmente no parecerá ser una falla del puente. En la práctica, es fácil buscar en el lugar equivocado, como las reglas del firewall, DNS, STAS o el controlador de dominio.

Comprender la dirección del tráfico afectado

Hay que separar claramente tres tipos de tráfico.

Los tipos de tráfico difieren significativamente:

Tráfico que pasó a través del puente: Un cliente en VLAN 100 está hablando con un servidor en VLAN 100. Esto aún puede funcionar, pero no prueba que el tráfico hacia el firewall esté funcionando.
Tráfico al firewall: un cliente utiliza el firewall como servidor DNS o destino WebAdmin. Es precisamente este tráfico el que puede verse afectado porque termina en el firewall.
Tráfico desde el firewall: El firewall consulta destinos AD, DNS, LDAP, RADIUS, NTP o Syslog. Esto también es fundamental porque el propio firewall es el remitente.

Si solo se prueba una aplicación entre dos hosts, el error no se puede identificar con certeza. La prueba debe incluir deliberadamente un servicio que finalice en Sophos Firewall o que sea creado por el firewall.

Síntomas típicos

Los posibles signos son:

Las reglas basadas en el usuario ya no funcionan de manera confiable porque no se puede acceder a AD, STAS o LDAP de manera estable.
Las consultas DNS al firewall fallan desde VLAN individuales.
Ping o HTTPS en los servicios de firewall locales no funcionan desde un VLAN, aunque las reglas del firewall parecen plausibles.
La supervisión o Syslog aparece incompleta si el firewall tiene que alcanzar un objetivo en un VLAN etiquetado.
Packet Capture muestra que el tráfico entre los sistemas finales es visible, pero los propios servicios de firewall no responden como se esperaba.
Después de una actualización SFOS-22, los síntomas ocurren sin cambiar nada conscientemente en las reglas del conmutador o del firewall.

Estos síntomas no deben abordarse de inmediato con reglas amplias de autorización o aprobaciones de acceso a dispositivos. En primer lugar, debe quedar claro si el diseño de la interfaz en sí se ve afectado.

Demarcación rápida antes de la conversión

Antes de mover un puente IP o crear nuevas interfaces VLAN en el puente, debe delimitar la causa. No todos los problemas después de una actualización son automáticamente el caso SFOS-22-Bridge-VLAN.

Clasificación práctica:

Una sola aplicación entre dos hosts no funciona: Lo más probable es que sea la regla de firewall, NAT, el sistema de destino o la ruta de retorno. Primero probar regla de firewall y para caídas analizar paquetes descartados.
WebAdmin, DNS o ping al firewall desde un VLAN no funciona: Marque Device Access, zona, servicio local o puente VLAN caso especial. Luego pruebe el tráfico al firewall por separado.
El firewall no llega a AD, LDAP, RADIUS, DNS o Syslog en VLAN: Verifique el tráfico desde el firewall, enrutamiento, DNS o puente VLAN caso especial. Utilice pruebas directamente desde la configuración del firewall y los registros de servicio apropiados.
Se está ejecutando el tráfico normal del cliente, pero los servicios del firewall en sí no: El caso especial del puente VLAN se vuelve más probable. Verifique el diseño del puente, la configuración antigua de la etiqueta CLI VLAN y la interfaz VLAN para el puente.
No hay ninguna entrada de registro coincidente: Verifique el registro, el filtro, el servicio local o el puente no registrado/NAT caso especial. Combine Log Viewer, Packet Capture y Sophos Firewall registros de servicio relevantes.

Para problemas de DNS, también es importante si los clientes usan el firewall como solucionador o si el firewall mismo usa rutas de solicitud de DNS a servidores internos. El segundo caso se refiere al tráfico procedente del firewall y puede parecer diferente al tráfico normal del cliente para problemas del Puente VLAN. Los conceptos básicos se encuentran en Configuración de rutas de solicitud de DNS en Sophos Firewall.

Si la demarcación rápida apunta claramente a servicios de firewall locales o al tráfico generado por el firewall, aún así se debe planificar la conversión. Una corrección de puente sin respaldo, ventana de mantenimiento y ruta de acceso alternativa es demasiado arriesgada para las redes productivas.

Incluir diseño existente

Antes de realizar cambios, debe documentar el estado actual. Particularmente importantes son:

Nombre de la interfaz del puente, por ejemplo br0.
Miembros del puente, es decir, interfaces físicas participantes, VLAN, interfaces RED o LAG.
Dirección IP del puente, si está disponible.
VLAN ID que pasan por el puente.
Perfil de puerto del switch: Tagged VLAN, Native VLAN, Trunk o puerto de acceso.
Servicios que finalizan en el firewall: DNS, Ping, HTTPS, SSH, User Portal, VPN Portal.
Servicios a los que debe llegar el firewall: AD, LDAP, RADIUS, DNS, NTP, Syslog, Central, Monitoreo.

Si la estructura proviene de una migración anterior, también debe verificar si las VLAN se configuraron mediante la configuración CLI. Es precisamente este legado el que a menudo ya no se tiene en cuenta cuando el cortafuegos sólo se ha actualizado a lo largo de los años.

⚠️ No debe experimentar espontáneamente con interfaces puente y VLAN durante las operaciones diarias. Un cambio incorrecto puede afectar el acceso a la administración, el DNS, la autenticación o redes de clientes completas. Antes de la corrección, se requiere una copia de seguridad, una ventana de mantenimiento y una ruta de acceso alternativa.

Obstáculos específicos de bridge antes de la corrección

Sophos describe tres restricciones de bridge que conviene comprobar conscientemente antes del cambio.

Primero: un bridge sin dirección IP puede descartar tráfico si este coincide con una regla de firewall con filtrado web proxy o con una regla NAT. Según Sophos, estos descartes no se registran. Si una regla NAT sigue siendo necesaria, debe estar acotada de forma que la traducción de origen para el bridge sin dirección IP permanezca en Original. De lo contrario, se puede buscar en Log Viewer un descarte que nunca aparece allí.

Segundo: el VLAN filtering del bridge solo se aplica al tráfico bridgeado, no al tráfico enrutado. Si Filter VLANs está activado, pero no se introducen VLAN IDs permitidos, se descarta el tráfico etiquetado de todos los VLANs; el tráfico sin etiquetar queda excluido. Durante las pruebas, esto puede parecer un problema VLAN incoherente.

Tercero: las interfaces bridge no sustituyen a cualquier diseño. Sophos enumera restricciones para Dynamic DNS, DHCP client, PPPoE e IPsec VPN. Si una de estas funciones forma parte del diseño objetivo, no conviene aplicar el workaround del bridge de forma aislada; se debe reevaluar el diseño de interfaces.

Solución alternativa y preparación de la actualización

Una forma práctica es crear interfaces VLAN en Network > Interfaces utilizando la interfaz puente como interfaz principal.

Los diseños nuevos o corregidos ya no deberían basarse en system vlan-tag. Si todavía existen estas etiquetas CLI, deben documentarse, migrarse a interfaces VLAN en WebAdmin y solo después continuar con la actualización de firmware. Esto reduce tanto el caso especial de puente en SFOS 22 como bloqueos posteriores de actualización.

Ejemplos:

VLAN 100: br0.100
VLAN 200: br0.200

Al crear el VLAN en WebAdmin, tres campos son decisivos: Interface debe ser el bridge, Zone debe corresponder al propósito de seguridad del VLAN y VLAN ID debe ser único. Sophos permite IDs de VLAN en WebAdmin de 1 a 4094; no se debería planificar el mismo VLAN ID más de una vez en el mismo parent interface.

El proceso depende de si el puente ya tiene una dirección IP.

Si el puente no necesita una dirección IP

Si el puente solo debe reenviar de forma transparente, puede funcionar sin dirección IP propia. La dirección IP para el VLAN afectado está entonces en la interfaz VLAN, por ejemplo br0.100.

Proceso práctico:

Cree una copia de seguridad.
Documente el puente actual y la configuración VLAN.
Agregue una nueva interfaz VLAN en Network > Interfaces.
Seleccione el puente como interfaz principal, por ejemplo br0.
Ingrese VLAN ID.
Elige tu zona conscientemente.
Establezca la dirección IP en la interfaz VLAN si el firewall debe estar en este VLAN Gateway o servicio local.
Marque Device Access para la zona.
Verifique las reglas del firewall y las reglas NAT.
Validar con un cliente de prueba.

La zona no es sólo orden en el WebAdmin. Esta decisión afecta las reglas del firewall, Device Access, los registros y muchos pasos posteriores de solución de problemas. Si un VLAN está destinado a ser una red de administración, servidor o cliente, esto debería estar visible en la zona.

Si el puente anteriormente tenía la dirección productiva IP

Si el puente utiliza actualmente la dirección IP, a la que debe ser accesible en VLAN en el futuro, debe tener especial cuidado. Hay dos variantes limpias para la conversión: el puente recibe una dirección IP diferente o el puente permanece sin una dirección IP. Luego, la dirección productiva anterior se asigna a la interfaz VLAN.

Este es un cambio con riesgo de fracaso. Conviene aclarar previamente:

¿Qué dirección se utiliza para llegar a WebAdmin?
¿Qué clientes utilizan el firewall por defecto Gateway?
¿Qué configuraciones de DNS o DHCP apuntan a esta dirección?
¿Qué reglas de acceso a dispositivos se aplican a la zona anterior?
¿Existe un segundo acceso de administración desde una red no afectada?

Para ubicaciones remotas, este cambio no debe planificarse sin una ruta de retorno local. Si WebAdmin y SSH pasan exactamente por el puente afectado IP, un error puede interrumpir el acceso administrativo.

Device Access y luego verifique las reglas del firewall

Después de crear la interfaz VLAN, no basta con probar la dirección IP. Device Access y las reglas del firewall deben coincidir con el nuevo diseño de interfaz y zona.

Para comprobar:

Administration > Device access: ¿Los portales Ping/Ping6, DNS, HTTPS, SSH, User Portal o VPN solo se permiten en las zonas correctas?
Rules and policies > Firewall rules: ¿Existen reglas para la nueva zona?
Rules and policies > NAT rules: ¿El tráfico se traduce inesperadamente?
Network > DNS o rutas de solicitud de DNS: ¿el firewall está llegando a los servidores DNS o AD correctos?
Authentication > Servers: ¿Se puede acceder a AD, LDAP o RADIUS después del cambio? Para los servicios de firewall locales, Device Access configurar de forma segura Sophos Firewall es el artículo detallado adecuado. Sophos Firewall Probar regla con Log Viewer y Packet Capture ayuda al análisis de reglas.

Validación después de la corrección

Una prueba limpia debe contener más de un ping.

Test del afectado VLAN

Consulta de un cliente en el VLAN afectado:

Alcance el valor predeterminado Gateway.
Pruebe el firewall IP en la nueva interfaz VLAN mediante ping, si está permitido.
Pruebe DNS contra el firewall si el firewall sirve como solucionador de DNS.
Pruebe WebAdmin o el portal solo desde las redes de administración permitidas.
Verifique una aplicación típica o una conexión de servidor.
Verifique que Log Viewer coincida con el ID de regla y la zona.

Prueba desde el firewall

Se requieren pruebas separadas para el tráfico que genera el propio firewall:

Pruebe los servidores AD o LDAP en Authentication > Servers.
Verifique la resolución de DNS a través del firewall.
Marque NTP, Syslog o el objetivo de monitoreo si estos servicios están en VLAN.
Utilice Packet Capture en la interfaz VLAN cuando no esté claro si los paquetes salen del firewall.

Si STAS o las reglas basadas en usuarios se ven afectadas, también se debe marcar Configurar STAS en Sophos Firewall. Para las actualizaciones SFOS-22, este punto también pertenece a la SFOS 22 Upgrade Check.

Errores comunes

Errores típicos:

Pruebe únicamente el tráfico de cliente a servidor: El puente parece estar en buen estado, aunque los servicios de firewall locales se ven afectados. Pruebe también el tráfico hacia y desde el firewall.
Mover puente IP sin plan: WebAdmin, DNS o Gateway pueden fallar. Preparar copias de seguridad, ventanas de mantenimiento y acceso alternativo.
Seleccione zona incorrectamente para la nueva interfaz VLAN: Las reglas, Device Access y los registros no encajan. Elija una zona por motivos de seguridad, no por costumbre.
Device Access abierto demasiado ancho: El problema parece resuelto, pero los servicios de administración son innecesariamente accesibles. Local Service ACL planea específicamente.
No verifique el puerto del conmutador: VLAN llega incorrecto o sin etiquetar. Validar el perfil Tagged/Untagged, Native VLAN y Trunk.
Ignorar la configuración CLI anterior: El error permanece sin explicación después de la actualización. Documente el diseño antiguo y migre a interfaces WebAdmin-VLAN.

Lista de verificación

Se comprobó la versión SFOS y la relevancia del problema conocido.
Interfaz del puente, miembros del puente e ID VLAN documentados.
Se aclaró si se utilizó la configuración antigua de la etiqueta CLI VLAN.
Drops específicos de bridge por NAT/web proxy y VLAN filtering comprobados.
Actualización planificada a SFOS 22.0 MR2 o posterior revisada frente a legacy CLI VLAN tags.
Servicios afectados hacia y desde el firewall identificados.
Acceso de respaldo y administración alternativa disponible.
Interfaz VLAN planificada con puente como interfaz principal.
Zona, Device Access, reglas de firewall y reglas NAT marcadas.
Pruebas realizadas desde el VLAN y desde el firewall.
Resultado registrado en el registro de cambios o en la documentación de la red.

Preguntas frecuentes

¿Por qué el tráfico normal funciona a través del puente pero el DNS al firewall no?

En este caso especial SFOS-22, el tráfico VLAN transferido puede seguir funcionando, mientras que el tráfico etiquetado VLAN que finaliza o se origina en el firewall se ve afectado. Por lo tanto, debe probar los servicios de firewall locales por separado.

¿Debería generalmente evitar puentear VLAN en Sophos Firewall?

Generalmente no. Los puentes pueden resultar útiles para migraciones o diseños transparentes. Sin embargo, para las nuevas redes segmentadas, las interfaces VLAN separadas con zonas claras suelen ser más claras y fáciles de operar.

¿Se puede solucionar el problema con una regla de firewall?

No confiable. Si el diseño de la interfaz se ve afectado, una regla Permitir adicional no cambiará la causa. Primero deberías comprobar si el VLAN debe crearse correctamente como interfaz en el puente.

¿Qué debería comprobar antes de realizar cambios en el puente IP?

Debe aclarar si WebAdmin, DNS, DHCP, Gateway predeterminado, autenticación o monitoreo utilizan esta dirección. Además, se requiere una copia de seguridad actual y una ruta de acceso alternativa.