Verificar VLANs de puente en Sophos Firewall después de SFOS 22

Las interfaces de puente en Sophos Firewall son prácticas cuando se desea continuar de manera transparente con una red de capa 2 existente o realizar una migración sin cambios inmediatos de IP. Sin embargo, con VLANs en un puente, el diseño puede volverse rápidamente propenso a errores: entonces hay reenvío entre redes, tráfico hacia el propio firewall, Device Access, DNS, AD, autenticación y, a menudo, configuraciones antiguas de CLI.

Precisamente en este punto hay un caso operativo importante en SFOS 22. Sophos enumera en la lista actual de problemas conocidos un problema en el que las interfaces de puente con configuraciones de CLI VLAN tag en SFOS 22.0 GA y SFOS 22.0 MR1 no procesan correctamente el tráfico etiquetado con VLAN cuando este tráfico se origina desde el propio Sophos Firewall o termina en el firewall. Esto puede afectar, por ejemplo, a Active Directory, DNS, Device Access, STAS, LDAP, RADIUS o acceso de gestión, aunque el tráfico normal se reenvíe a través del puente.

Este artículo no es un capítulo general sobre fundamentos de VLAN. Para la planificación de zonas, interfaces, VLANs, puentes y LAGs, primero consulte Configurar zonas e interfaces en Sophos Firewall. Aquí nos enfocamos específicamente en el caso especial de VLAN de puente después de SFOS 22.

Cuándo es relevante este tema

La verificación es útil cuando se combinan varios puntos:

• El firewall está ejecutando SFOS 22.0 GA o SFOS 22.0 MR1.
• Hay una interfaz de puente, por ejemplo, br0.
• Las VLANs se construyeron históricamente mediante configuraciones de CLI VLAN tag como system vlan-tag o se heredaron de una configuración antigua.
• Los servicios del propio firewall deben alcanzar una VLAN etiquetada.
• Después de una actualización, AD, DNS, autenticación, monitoreo o acceso de gestión solo funcionan parcialmente.
• El tráfico normal de clientes a través del puente parece seguir funcionando.

El último punto es importante: si el puente sigue reenviando tráfico entre redes, el problema inicialmente no parece un error del puente. En la práctica, se busca rápidamente en el lugar equivocado, como en las reglas del firewall, DNS, STAS o el controlador de dominio.

Entender la dirección del tráfico afectado

Es necesario separar claramente tres tipos de tráfico.

Si solo se prueba una aplicación entre dos hosts, no se detecta el error de manera segura. La prueba debe incluir conscientemente un servicio que termine en Sophos Firewall o sea generado por el firewall.

Síntomas típicos

Los posibles signos son:

• Las reglas basadas en usuarios ya no funcionan de manera confiable porque AD, STAS o LDAP no son accesibles de manera estable.
• Las consultas DNS al firewall fallan desde algunas VLANs.
• Ping o HTTPS a servicios locales del firewall no funcionan desde una VLAN, aunque las reglas del firewall parezcan plausibles.
• El monitoreo o Syslog parece incompleto cuando el firewall debe alcanzar un destino en una VLAN etiquetada.
• Packet Capture muestra que el tráfico entre sistemas finales es visible, pero los servicios del propio firewall no responden como se esperaba.
• Después de una actualización a SFOS 22, los síntomas aparecen sin que se haya cambiado conscientemente nada en el switch o en las reglas del firewall.

Estos síntomas no deben responderse inmediatamente con reglas de permiso amplias o habilitaciones de Device Access. Primero debe quedar claro si el diseño de la interfaz en sí está afectado.

Delimitación rápida antes de la reestructuración

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

Para problemas de DNS, también es importante si los clientes utilizan el firewall como resolver o si el propio firewall utiliza rutas de solicitud DNS hacia servidores internos. El segundo caso afecta al tráfico desde el firewall y puede verse diferente en problemas de VLAN de puente que el tráfico normal de clientes. Los fundamentos están en Configurar rutas de solicitud DNS en Sophos Firewall.

Si la delimitación rápida indica claramente servicios locales del firewall o tráfico generado por el firewall, aún así se debe planificar la reestructuración. Una corrección de puente sin respaldo, ventana de mantenimiento y ruta de acceso alternativa es demasiado arriesgada en redes productivas.

Documentar el diseño existente

Antes de realizar cambios, se debe documentar el estado actual. Son especialmente importantes:

• Nombre de la interfaz de puente, por ejemplo, br0.
• Miembros del puente, es decir, interfaces físicas involucradas, VLANs, interfaces RED o LAGs.
• Dirección IP del puente, si existe.
• IDs de VLAN que pasan por el puente.
• Perfil de puerto del switch: VLANs etiquetadas, VLAN nativa, puerto troncal o de acceso.
• Servicios que terminan en el firewall: DNS, Ping, HTTPS, SSH, User Portal, VPN Portal.
• Servicios que el firewall debe alcanzar: AD, LDAP, RADIUS, DNS, NTP, Syslog, Central, monitoreo.

Si la configuración proviene de una migración antigua, también se debe verificar si las VLANs se configuraron mediante CLI. Esta carga heredada a menudo ya no se tiene en cuenta cuando el firewall solo se ha actualizado durante años.

⚠️ No se debe experimentar espontáneamente con interfaces de puente y VLANs durante las operaciones diarias. Un cambio incorrecto puede afectar el acceso de gestión, DNS, autenticación o redes de clientes completas. Antes de la corrección, se necesita un respaldo, una ventana de mantenimiento y una ruta de acceso alternativa.

Solución temporal: Crear interfaces VLAN en el puente

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

Ejemplos:

El procedimiento 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 manera transparente, puede operar sin su propia dirección IP. La dirección IP para la VLAN afectada se encuentra entonces en la interfaz VLAN, por ejemplo, br0.100.

Procedimiento práctico:

1. Crear un respaldo.
2. Documentar la configuración actual del puente y VLAN.
3. En Network > Interfaces, agregar una nueva interfaz VLAN.
4. Seleccionar el puente como interfaz principal, por ejemplo, br0.
5. Ingresar la ID de VLAN.
6. Elegir conscientemente la zona.
7. Establecer la dirección IP en la interfaz VLAN si el firewall debe ser gateway o servicio local en esta VLAN.
8. Verificar Device Access para la zona.
9. Verificar reglas de firewall y NAT.
10. Validar con un cliente de prueba.

La zona no es solo orden en WebAdmin. Esta decisión influye en las reglas del firewall, Device Access, registros y muchos pasos posteriores de resolución de problemas. Si una VLAN está destinada a ser una red de gestión, servidor o cliente, esto debe ser visible en la zona.

Si el puente actualmente tiene la dirección IP productiva

Si el puente actualmente utiliza la dirección IP que debe ser accesible en la VLAN en el futuro, se debe proceder con especial cuidado. Para la reestructuración hay dos variantes limpias: el puente recibe una dirección IP diferente, o el puente permanece sin dirección IP. La dirección productiva actual se asigna posteriormente a la interfaz VLAN.

Este es un cambio con riesgo de interrupción. Antes se debe aclarar:

• ¿A través de qué dirección se accede a WebAdmin?
• ¿Qué clientes utilizan el firewall como gateway predeterminado?
• ¿Qué configuraciones de DNS o DHCP apuntan a esta dirección?
• ¿Qué reglas de Device Access dependen de la zona anterior?
• ¿Existe un segundo acceso de gestión desde una red no afectada?

En ubicaciones remotas, este cambio no debe planificarse sin una ruta de retorno local. Si WebAdmin y SSH funcionan exactamente a través de la IP de puente afectada, un error puede interrumpir el acceso administrativo.

Verificar Device Access y reglas del firewall después

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

A verificar:

• Administration > Device access: ¿Están Ping/Ping6, DNS, HTTPS, SSH, User Portal o VPN Portal permitidos solo en las zonas correctas?
• Rules and policies > Firewall rules: ¿Existen reglas para la nueva zona?
• Rules and policies > NAT rules: ¿Se traduce el tráfico inesperadamente?
• Network > DNS o rutas de solicitud DNS: ¿El firewall alcanza los servidores DNS o AD correctos?
• Authentication > Servers: ¿Son accesibles AD, LDAP o RADIUS después del cambio?

Para servicios locales del firewall, Configurar Device Access de manera segura en Sophos Firewall es el artículo de profundización adecuado. Para el análisis de reglas, ayuda Probar regla de Sophos Firewall con Log Viewer y Packet Capture.

Validación después de la corrección

Una prueba limpia debe incluir más que un ping.

Prueba desde la VLAN afectada

Desde un cliente en la VLAN afectada, verificar:

1. Alcanzar el gateway predeterminado.
2. Probar la IP del firewall en la nueva interfaz VLAN mediante ping, si está permitido.
3. Probar DNS contra el firewall si el firewall actúa como resolver DNS.
4. Probar WebAdmin o Portal solo desde redes de gestión permitidas.
5. Probar una aplicación típica o conexión de servidor.
6. Controlar Log Viewer en busca de ID de regla y zona adecuadas.

Prueba desde el firewall

Para el tráfico que el propio firewall genera, se necesitan pruebas separadas:

• Probar servidor AD o LDAP en Authentication > Servers.
• Verificar resolución DNS a través del firewall.
• Probar NTP, Syslog o destino de monitoreo si estos servicios están en la VLAN.
• Usar Packet Capture en la interfaz VLAN si no está claro si los paquetes salen del firewall.

Si STAS o reglas basadas en usuarios están afectadas, también se debe verificar Configurar STAS en Sophos Firewall. En actualizaciones a SFOS 22, este punto también pertenece al Check de actualización a SFOS 22.

Errores comunes

Lista de verificación

• Versión de SFOS y relevancia de problemas conocidos verificados.
• Documentados interfaz de puente, miembros del puente e IDs de VLAN.
• Aclarado si se utilizó configuración antigua de CLI VLAN tag.
• Identificados servicios afectados hacia y desde el firewall.
• Respaldo y acceso de gestión alternativo disponibles.
• Planificada interfaz VLAN con puente como interfaz principal.
• Verificadas zona, Device Access, reglas del firewall y reglas NAT.
• Realizadas pruebas desde la VLAN y desde el firewall.
• Resultado registrado en el registro de cambios o en la documentación de red.

Preguntas frecuentes