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, comprobar por separado la ruta de actualización y los bloqueos aplicables a esa build 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.
• Se planifica una actualización a SFOS 22.0 MR2 o posterior, o está bloqueada por legacy CLI VLAN tagging.
• El tráfico normal de clientes a través del puente parece seguir funcionando.

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

Distinguir tres tipos de tráfico:

• 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 trasladar la dirección IP del bridge 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 una VLAN no funciona: Compruebe Device Access, la zona, el servicio local o el caso especial de VLAN en bridges. 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, era necesario utilizar system vlan-tag para habilitar la comunicación con etiquetas VLAN a través de interfaces bridge. Desde SFOS 18.0, VLAN-over-bridge está disponible íntegramente en WebAdmin. Sin embargo, hay un límite importante que debe tenerse en cuenta al realizar el inventario y la limpieza: la documentación de etiquetas VLAN para SFOS 22 y 23 describe un reset con argumentos de interfaz también como una operación de visualización de la configuración. De ello no puede deducirse que system vlan-tag show sea una consulta independiente que no modifique la configuración, ni que system vlan-tag reset sin argumentos sea un comando de limpieza con un alcance conocido. La disponibilidad de un comando en un contexto CLI tampoco confirma estas propiedades.

Antes de cualquier acción por CLI para realizar el inventario o la limpieza, debe confirmarse mediante documentación inequívoca para la build instalada o a través de Sophos Support cuál es el método exacto que permite obtener el inventario sin modificar la configuración y qué sintaxis de limpieza corresponde. Esto incluye el contexto CLI exacto, los privilegios y argumentos necesarios, las interfaces o los nodos afectados, así como los efectos y el alcance de la limpieza. Si estos puntos no están aclarados, documente únicamente el inventario visible en WebAdmin, en Network > Interfaces, y deténgase antes de realizar la limpieza o la actualización. La ausencia de entradas en WebAdmin no demuestra que no existan etiquetas heredadas por CLI; aclare la cuestión pendiente del inventario con Sophos Support en lugar de probar un supuesto comando de visualización o reset.

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:

1. Exporte una copia de seguridad como documentación, pero no cuente con restaurarla para revertir el cambio en SFOS 22.
2. Documente el puente actual y la configuración VLAN.
3. En Network > Interfaces, seleccione Add interface > Add VLAN.
4. Seleccione el puente como interfaz principal, por ejemplo br0.
5. Ingrese VLAN ID.
6. Elige tu zona conscientemente.
7. Configure la dirección IP en la interfaz VLAN si el firewall debe actuar como gateway o prestar un servicio local en esa VLAN.
8. Compruebe Device Access para la zona.
9. Verifique las reglas del firewall y las reglas NAT.
10. 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 como gateway predeterminado?
• ¿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 utilizan precisamente la dirección IP afectada del bridge, un error puede interrumpir el acceso administrativo.

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

El orden es fundamental: una vez aclarados los puntos anteriores, cree primero todas las interfaces VLAN necesarias en Network > Interfaces, con el bridge como Parent Interface; traslade, si es necesario, la IP actual del bridge a la interfaz VLAN correspondiente y compruebe las nuevas rutas de datos y administración. En un entorno HA, confirme previamente mediante la visualización de estado admitida que el peer y la sincronización no presentan errores, y cree una copia de seguridad de cada nodo cuando así lo contemplen la plataforma y el procedimiento de soporte. Si el estado del peer o de la sincronización presenta errores o no está claro, deténgase antes de la limpieza o la actualización y escale el caso. No invente comandos de HA o sincronización.

Solo cuando la correspondencia entre interfaces esté documentada, haya un acceso alternativo activo y se cumplan todos los requisitos de HA, podrá eliminarse el ajuste heredado mediante el procedimiento confirmado para la build instalada mediante la ayuda de esa build o por Sophos Support. Antes de ejecutarlo, debe disponerse de la confirmación de la sintaxis exacta, el contexto CLI, los efectos y el alcance en cuanto a interfaces y nodos; este artículo no autoriza la ejecución de un comando reset sin esas condiciones. Si falta la confirmación, limítese al inventario de WebAdmin y deténgase antes de la limpieza o la actualización.

A continuación, utilice el método de inventario previamente confirmado como no modificador para comprobar específicamente si el ajuste heredado se ha eliminado dentro del alcance previsto. Las pruebas de tráfico por sí solas no lo demuestran. Si sigue siendo visible una configuración heredada, la limpieza falla o el inventario no es inequívoco, detenga el proceso: no inicie todavía la actualización ni apruebe la nueva copia de seguridad como punto de restauración limpio. Guarde las evidencias de inventario disponibles, la salida de los comandos si la hubiera, la comprobación previa a la actualización y la configuración actual, y escale el caso a Sophos Support; no pruebe comandos CLI no documentados.

La descripción contradictoria del reset tampoco permite deducir un método fiable de reversión mediante comandos. Superar las comprobaciones de inventario y las pruebas de tráfico confirma la limpieza, no la posibilidad de revertirla. Después de la limpieza, no vuelva a crear el ajuste heredado con un comando supuesto. Si es necesario revertir el cambio, deténgase e implique a Sophos Support para realizar una restauración aprobada por el fabricante en el firmware original admitido; revierta los cambios de WebAdmin únicamente dentro de ese plan aprobado.

Si las pruebas de aceptación y la nueva comprobación del inventario se completan correctamente, cree una nueva copia de seguridad, repita la comprobación previa a la actualización y solo entonces actualice a SFOS 22.0 MR2 o posterior. Para obtener un estado que pueda restaurarse en el futuro, se aplica el mismo procedimiento de limpieza confirmado: elimine el ajuste heredado en el firewall de origen, cree si es necesario una interfaz VLAN con el bridge como Parent, verifique el resultado y solo después genere una nueva copia de seguridad. Esto no repara una copia de seguridad antigua 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 servicios Ping/Ping6, DNS, HTTPS, SSH, User Portal o VPN Portal 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

Comprobaciones desde un cliente en la VLAN afectada:

1. Compruebe que se puede acceder al gateway predeterminado.
2. Pruebe mediante ping la IP del firewall en la nueva interfaz VLAN, si está permitido.
3. Pruebe DNS contra el firewall si el firewall actúa como resolver DNS.
4. Pruebe WebAdmin o el portal solo desde las redes de administración permitidas.
5. Verifique una aplicación típica o una conexión de servidor.
6. 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.
• Compruebe NTP, Syslog o el destino de monitoreo si estos servicios están en la 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 debe revisarse 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, registre la IP actual del bridge, la zona, los VLAN IDs, la configuración de los puertos del switch y las reglas y servicios dependientes. También se necesita un acceso de administración alternativo o local y un plan de recuperación aprobado por el fabricante. Mientras no se haya ejecutado la limpieza por CLI confirmada, los cambios previstos en WebAdmin pueden revertirse en el orden documentado: retire primero la dirección IP trasladada de la nueva interfaz VLAN y solo después vuelva a asignarla al bridge; a continuación, restaure la zona, las reglas, Device Access y el perfil del puerto del switch, y compruebe la conectividad de administración y con el gateway. Esto no revierte una limpieza por CLI.

La descripción contradictoria del reset no demuestra que exista una reversión mediante comandos. Si las pruebas de aceptación fallan después de la limpieza confirmada, deténgase y no vuelva a crear el ajuste heredado. Escale el caso para realizar una restauración aprobada por el fabricante en el firmware original admitido. En HA, no limpie ni actualice ningún nodo mientras el estado del peer o de la sincronización presente errores o no esté claro; conserve la copia de seguridad requerida de cada nodo. Sin la confirmación previa necesaria del método de inventario, la sintaxis de limpieza, el contexto, los efectos y el alcance, limítese al inventario de WebAdmin y deténgase antes de la limpieza o la actualización.

Tras superar las pruebas de aceptación, se genera una nueva copia de seguridad. La copia de seguridad antigua con Legacy CLI VLAN tagging no permite volver atrás en SFOS 22.0 GA o posterior. Si la configuración heredada persiste pese a la migración en WebAdmin, o la comprobación previa a la actualización sigue notificándola, no experimente con más cambios por CLI: guarde la configuración y el mensaje e implique a Sophos Support.

Errores comunes

Errores típicos:

• Probar ú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.
• Trasladar la IP del bridge sin un plan: WebAdmin, DNS o Gateway pueden fallar. Preparar copias de seguridad, ventanas de mantenimiento y acceso alternativo.
• Elegir una zona incorrecta 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. Planifique las Local Service ACL de forma específica.
• No comprobar el puerto del switch: 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 comprobadas.
• Pruebas realizadas desde el VLAN y desde el firewall.
• Método de inventario que no modifica la configuración, sintaxis exacta de limpieza, contexto CLI, efectos y alcance confirmados para la build instalada mediante documentación o por Sophos Support antes de cualquier acción por CLI; de lo contrario, solo inventario de WebAdmin y detención antes de la limpieza o la actualización.
• Límite de recuperación documentado: la descripción contradictoria del reset no permite deducir una vía de reversión mediante comandos; nueva copia de seguridad creada tras la limpieza confirmada y la superación de las pruebas de aceptación.
• Resultado registrado en el registro de cambios o en la documentación de la red.

Preguntas frecuentes