Sustituir el etiquetado VLAN heredado antes de SFOS 22 MR2

Las interfaces bridge de Sophos Firewall resultan útiles para mantener transparente una red de capa 2 o realizar una migración sin cambiar de inmediato las direcciones IP. Si anteriormente se configuraron etiquetas VLAN en un bridge con system vlan-tag, hay que sustituirlas por interfaces VLAN en WebAdmin antes de actualizar a SFOS 22.0 MR2 o una versión posterior. No es un cambio meramente estético: en GA y MR1 puede fallar el tráfico dirigido al firewall o generado por él, y desde MR2 esa configuración heredada bloquea la actualización.

El problema NC-181672 afecta a las interfaces bridge con configuraciones CLI VLAN tag en SFOS 22.0 GA y SFOS 22.0 MR1: el tráfico etiquetado con VLAN que se origina en Sophos Firewall o termina en el firewall no se procesa correctamente. Esto puede afectar a Active Directory, DNS, Device Access, STAS, LDAP, RADIUS o al acceso de administración, aunque el bridge siga reenviando el tráfico normal.

El etiquetado VLAN heredado por CLI está obsoleto: bloquea la actualización a SFOS 22.0 MR2 o posterior, y una copia de seguridad que lo contenga no puede restaurarse en SFOS 22.0 GA o posterior. Por eso esta revisión debe realizarse antes de actualizar y antes de crear la copia de seguridad destinada a la actualización. La comprobación de actualización a SFOS 22 documenta la versión de destino verificada MR2 Build 546, su ruta de actualización y otros bloqueos específicos. Si se prevé otra build de destino, esta comprobación interna debe actualizarse antes del cambio; los datos de MR2 no deben trasladarse sin verificarlos.

Este artículo no es un capítulo general sobre VLAN. Para planificar zonas, interfaces, VLAN, bridges y LAG, conviene empezar por Configurar zonas e interfaces en Sophos Firewall. El procedimiento normal de configuración, protección y validación se explica en Configurar una interfaz bridge en Sophos Firewall. Aquí se trata específicamente el caso especial de las VLAN en bridges 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

Antes del cambio deben comprobarse cuidadosamente tres restricciones de bridge.

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. 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. Existen 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

El workaround admitido es crear interfaces VLAN en Network > Interfaces usando el bridge como parent. Las interfaces físicas, RED, bridge y LAG son parents válidos.

Antes de SFOS 18.0, system vlan-tag era necesario para activar tráfico VLAN etiquetado sobre bridges. Desde SFOS 18.0, VLAN-over-bridge está disponible en WebAdmin. Para el siguiente comando CLI no se especifican Device Console, Advanced Shell, número de menú, prompt ni nivel de privilegio. Use únicamente el contexto CLI admitido del firewall donde el comando esté disponible. Si no lo está, deténgase y consulte a Sophos Support en vez de adivinar el shell o el contexto. Compruebe primero la configuración heredada con este comando de solo lectura:

system vlan-tag show

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. WebAdmin admite IDs de VLAN 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:

Exporte una copia de seguridad como documentación, pero no cuente con restaurarla para revertir el cambio en SFOS 22.
Documente el puente actual y la configuración VLAN.
En Network > Interfaces, seleccione Add interface > Add VLAN.
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.
Valide el cambio con un cliente de prueba y cree una nueva copia de seguridad solo después de superar las pruebas.

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.

Eliminar la configuración heredada y preparar la actualización

Cree primero las interfaces VLAN necesarias en Network > Interfaces con el bridge como parent, mueva si es necesario la IP del bridge a la interfaz VLAN correcta y valide las rutas de datos y administración. En HA, confirme mediante la interfaz de estado admitida que el peer y la sincronización están en buen estado, y haga backup de cada nodo cuando corresponda según la plataforma y el procedimiento de soporte. Si el estado no es correcto o no está claro, deténgase antes del reset o la actualización y escale; no invente comandos de HA o sincronización. Con el mapeo documentado, acceso alternativo activo y los requisitos de HA cumplidos, elimine el ajuste en el mismo contexto CLI admitido descrito arriba:

system vlan-tag reset

Ejecute de nuevo system vlan-tag show. Si queda configuración, falla el reset o la salida es ambigua, deténgase: no inicie la actualización ni apruebe el nuevo backup como punto limpio. Guarde la salida, el precheck y la configuración y escale a Sophos Support sin probar comandos no documentados. No existe una reversión documentada a nivel de comando para system vlan-tag reset: superar las comprobaciones posteriores confirma la limpieza, no la reversión. Tras el reset, no intente recrear el ajuste heredado con un comando supuesto. Si debe deshacer el cambio, deténgase y escale para que el proveedor apruebe una restauración en el firmware original admitido. Tras superar las pruebas, cree un backup nuevo, repita el precheck y solo entonces actualice. Para un backup restaurable, limpie igual el firewall de origen, cree opcionalmente la interfaz VLAN necesaria, valide y después haga el backup. Esto no repara un backup antiguo con system vlan-tag.

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.
En Diagnostics > Packet capture, revise la interfaz VLAN. Generated identifica paquetes creados por el firewall y Consumed los destinados a él; compare también In interface, Out interface, Rule ID, Status y Reason.

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.

Reversión y cierre

Antes del cambio, anote la dirección IP y la zona del bridge, los IDs de VLAN, el perfil del puerto del switch y las reglas y servicios dependientes. Prepare acceso de administración alternativo o local y un plan de recuperación aprobado por el proveedor. Antes de system vlan-tag reset, puede deshacer los cambios previstos de WebAdmin en el orden documentado: si trasladó la IP, elimínela primero de la interfaz VLAN y después vuelva a asignarla al bridge; restaure zona, reglas, Device Access y perfil del switch y compruebe la conectividad. Esto no revierte el reset. Después del reset no hay reversión documentada a nivel de comando: si falla la validación, deténgase y escale para una restauración aprobada por el proveedor en el firmware original admitido. En HA, no resetee ni actualice ningún nodo si el peer o la sincronización no están sanos o son inciertos, y conserve el backup aplicable de cada nodo.

Tras una validación correcta, cree un nuevo backup. El backup antiguo con legacy CLI VLAN tagging no sirve para volver atrás en SFOS 22.0 GA o posterior. Si el precheck aún lo detecta, guarde la configuración y el mensaje y contacte con Sophos Support sin probar más cambios CLI no documentados.

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.
Backup de cada nodo aplicable y acceso de administración alternativo disponibles; peer y sincronización de HA en buen estado.
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.
Límite de recuperación documentado: system vlan-tag reset no tiene reversión documentada; nuevo backup creado tras la corrección.
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.