Comprobación de actualización a SFOS 22: revisar bloqueadores

Antes de actualizar a SFOS 22, hay que confirmar que la plataforma, la ruta de actualización y la configuración son compatibles con la versión de destino. Esta comprobación tiene en cuenta SFOS 22.0 MR2 Build 546 del 14 de julio de 2026 y complementa la guía general de actualización de firmware de Sophos Firewall.

Bloqueadores estrictos de actualización y restauración

• Hardware XG o SG: SFOS 22 no es compatible. En lugar de una actualización, hay que migrar a XGS, una plataforma virtual, de software o cloud.
• Legacy Remote Access IPsec: A partir de SFOS 22.0 MR1, la configuración debe migrarse o eliminarse antes de la actualización.
• Legacy CLI VLAN Tagging en una interfaz Bridge: A partir de SFOS 22.0 MR2, system vlan-tag debe sustituirse por interfaces VLAN compatibles.
• Backup con Legacy VLAN Tagging: Para restaurar en SFOS 22.0 GA o posterior, hay que limpiar la configuración de origen y crear un backup nuevo.
• Almacenamiento o ruta de actualización: Si la página de firmware indica poco espacio de almacenamiento o una ruta de actualización no válida, primero hay que corregir la causa.

Si existe un bloqueador o algún punto no está claro, no se debe iniciar la actualización.

Ruta de actualización directa a SFOS 22.0 MR2

Para el destino tratado aquí, SFOS 22.0 MR2 Build 546, Sophos admite una actualización directa desde las siguientes versiones:

• SFOS 22.0: MR1 Build 490, así como GA Build 411 o 365
• SFOS 21.5: MR2 Build 323, MR1 Build 261 o GA Build 171
• SFOS 21.0: MR2 Build 349, MR1 Build 277, 272 o 237, así como GA Build 169
• Versiones anteriores: cualquier versión de SFOS 20.0, 19.5 o 19.0

⚠️ Si la versión actual no figura en esta lista, no se debe confirmar la advertencia de una migración no compatible. De lo contrario, el firewall se reinicia con los ajustes de fábrica y se pierde la configuración actual. Asimismo, un backup solo puede restaurarse desde una versión cuya migración de configuración sea compatible.

Para una versión anterior o que no figure en la lista, primero hay que planificar una ruta intermedia compatible. La lista de versiones tampoco sustituye las demás comprobaciones: la plataforma, el almacenamiento, los elementos heredados y el plan de restauración también deben ser adecuados.

Comprobaciones antes de la ventana de mantenimiento

Plataforma y elementos heredados

• Documentar el modelo y el firmware actual para poder seguir la ruta de actualización indicada arriba y una posible restauración.
• Tratar el hardware XG y SG como una migración, no como una actualización normal.
• Sustituir antes de la actualización los túneles SSL VPN de UTM9 y los dispositivos RED 15, RED 15w y RED 50.
• En Network > Interfaces, corregir los nombres que terminan en diez o más dígitos. Estos nombres pueden ocultar interfaces en WebAdmin después de la actualización.

Almacenamiento, backup y acceso

El uso de las particiones puede comprobarse de forma aproximada en Advanced Shell:

df -kh

Si aparece una advertencia en la página de firmware, todavía no debe iniciarse la actualización. El código de referencia indica la causa y el siguiente paso:

• FWDS501: El Primary Disk o una de sus particiones del sistema es demasiado pequeño para SFOS 22. En una VM implementada antes de SFOS 18, el mismo estado heredado puede aparecer inicialmente solo como un error genérico de firmware al actualizar a SFOS 21.5 o posterior (NC-151465); sin embargo, el mensaje por sí solo no demuestra un problema de disco. En un firewall virtual, ampliar el Primary Disk antes de SFOS 22 muestra cómo comprobar y ampliar Hard disk 1, y verificar después el resultado. El mismo artículo incluye los valores límite y las soluciones adecuados para una Software Appliance.
• FWDS502: No hay suficiente espacio libre en /var. En 4. Device Console, system firmware check-disk-space muestra el espacio necesario y las áreas de datos implicadas. Los reports o logs solo deben limpiarse de forma controlada después de guardar los datos necesarios; el procedimiento se describe en Comprobar el espacio y gestionar reports.
• FWDS503: La partición /content es demasiado pequeña. Sophos exige un factory reset con interrupción del servicio y pérdida de la configuración actual. Después de crear un backup reciente y guardar el SSMK, hay que introducir RESET en mayúsculas mediante la consola serie y seleccionar la opción 2; esto elimina las configuraciones propias y restablece las firmas de patrones al estado del firmware activo. A continuación, se restaura el backup, se comprueban las funciones y solo entonces se realiza la actualización. Los reports locales no se restauran.
• FWDS504: El firmware del SSD está obsoleto y debe actualizarse antes de actualizar SFOS.
• FWDS505: Sophos Support debe verificar el estado del SSD. Una comprobación SMART local puede documentar valores para Support, pero no elimina el bloqueo.

En un clúster HA se debe comprobar cada nodo por separado, ya que las dos appliances pueden mostrar códigos de referencia diferentes.

Antes de empezar, también debe estar disponible lo siguiente:

• un backup reciente almacenado externamente y el Secure Storage Master Key correspondiente
• acceso de administrador local o acceso alternativo fuera de la ruta VPN habitual
• una ruta de reversión definida con una persona responsable y un punto de decisión
• para HA, un clúster en buen estado y sincronizado, con enlaces HA y Monitored Ports estables

Los detalles sobre backup y restauración se encuentran en Crear o restaurar un backup de Sophos Firewall.

Configuraciones de especial riesgo

Legacy Remote Access IPsec

A partir de SFOS 22.0 MR1, una configuración existente de Legacy Remote Access IPsec bloquea la actualización. Primero hay que migrar los usuarios, pools y perfiles afectados a la configuración actual de Remote Access IPsec, SSL VPN, ZTNA u otro diseño adecuado. El procedimiento se describe en Migrar Legacy Remote Access IPsec antes de SFOS 22 MR1.

Microsoft Entra ID SSO con Same as firewall

SFOS 22.0 o posterior activa automáticamente Microsoft Entra ID SSO para VPN Portal, Remote Access IPsec y SSL VPN cuando su método de autenticación está configurado como Same as firewall antes de la actualización. Por ello, antes de la ventana de mantenimiento se documentan los ajustes de Authentication > Services y el proveedor de identidad realmente previsto.

Después de la actualización se comprueba cada método efectivo por separado. Si se desea Entra SSO, la VPN portal and remote access URL exacta del objeto de servidor Entra debe figurar como Redirect URI en la aplicación Entra; la URL reverse SSO de Sophos Central no es válida para este fin. Un inicio de sesión piloto real verifica el portal, el cliente y MFA. Si no se desea SSO, se configura expresamente el método previsto. El procedimiento completo se describe en Configurar Microsoft Entra ID SSO para VPN de Sophos Firewall.

Policy-based IPsec y NAT

Los túneles site-to-site policy-based en producción deben comprobarse antes y después de la actualización con un flujo de prueba concreto. Esto incluye Source, Destination, Service, Traffic Selectors, el dispositivo remoto y las reglas de firewall y NAT previstas. En caso de problemas, pueden consultarse Solución de problemas de VPN IPsec y Comprender NAT en Sophos Firewall.

Además, antes de actualizar hay que determinar si OSPF o BGP anunciaba redes VPN remotas policy-based mediante redistribute kernel. A partir de SFOS 22, estas redes dejan de estar disponibles como rutas normales del kernel; SFOS 22: rutas IPsec y redistribute kernel muestra qué prefijos deben comprobarse antes y después de la actualización y por qué un diseño XFRM route-based resulta más adecuado para el routing dinámico.

SMTP mediante DNAT

Si se publica un servidor de correo interno mediante DNAT, el plan de mantenimiento debería incluir varios mensajes de prueba entrantes reales, no solo una prueba de puerto. Bajo NC-184583, Sophos enumera conexiones SMTP interrumpidas de forma esporádica después de una actualización a SFOS 22.x; GA Respin Build 411 figura expresamente como versión afectada y no hay un workaround público. El alcance exacto de las versiones, la recopilación de evidencias y la escalación a Support se describen en Publicar un servidor mediante DNAT en Sophos Firewall.

Let’s Encrypt y rollback de la migración en MR2

MR2 Build 546 admite las nuevas CA de Let’s Encrypt YE Root, YE1, YE2, YR Root, YR1 y YR2. Independientemente de ello, en dos actualizaciones documentadas públicamente de MR1 Build 490 a MR2 Build 546, la migración de la configuración se interrumpió en relación con un certificado de Let’s Encrypt que estaba en uso. El firewall volvió automáticamente a MR1. Tras una comprobación mediante Support Access, Sophos confirmó un bloqueo de migración conocido para certificados de un periodo de emisión determinado, pero no delimitado públicamente. A 9 de agosto de 2026, sigue sin haber un ID público de la incidencia, una prueba previa fiable ni una versión con la corrección confirmada.

Antes de actualizar un firewall con MR1 y un certificado de Let’s Encrypt emitido o renovado recientemente, deben documentarse el Issuer y la asignación del servicio en Certificates > Certificates. Un Issuer YE/YR o la mera existencia de estas CA en Certificate authorities no demuestra el error de migración y, por sí solo, no constituye un bloqueo general de la actualización. En un firewall crítico, sigue siendo aconsejable acordar previamente el caso con Sophos Support o posponer la actualización mientras no se confirme una prueba previa pública o una corrección. Los certificados y las CA no deben eliminarse ni renombrarse por precaución: un intento de eliminación documentado en la Community no resolvió el error de forma fiable, y el certificado puede proteger WAF, WebAdmin, portales, Hotspot o SMTP TLS. Gestionar certificados en Sophos Firewall explica cómo comprobar las asignaciones y preparar un reemplazo seguro con una ruta de reversión.

Este rollback de la migración no es el mismo error que la entrega de una cadena de certificados incompleta después de la renovación. Certificados Let’s Encrypt en Sophos Firewall describe cómo comprobar este segundo problema y el hotfix desplegado para corregirlo.

Después de un rollback automático, el comportamiento coincide con el error conocido si dbv22.004 y tblvpncertificate_caid_fkey aparecen en migration.log y la instrucción de eliminación que los rodea menciona objetos YE/YR. Estos términos ayudan a localizar las líneas relevantes:

dbv22.004
tblvpncertificate_caid_fkey
Lets_Encrypt_YE
Lets_Encrypt_YR

Si aparecen, deben guardarse migration.log, migrationhash.log, el aviso de firmware, la hora y las builds de origen y destino, sin repetir la actualización sin cambios. Después hay que comprobar la versión de origen, HA, WAN, routing, VPN, la conexión con Central y todos los servicios que dependen de certificados. Guardar logs de Sophos Firewall para Support muestra cómo recopilar las evidencias; con estos datos, Sophos Support puede delimitar el error de migración.

Legacy VLAN Tagging en Bridges

Legacy CLI VLAN Tagging en interfaces Bridge tiene tres consecuencias:

• En GA y MR1 puede fallar el tráfico hacia o desde el firewall, mientras el tráfico de tránsito sigue funcionando.
• A partir de MR2, la actualización queda bloqueada.
• Un backup afectado no se puede restaurar en SFOS 22.0 GA o posterior.

Antes de limpiar la configuración, hay que documentar Bridge, VLAN IDs, direcciones IP, zonas, switch trunks y servicios dependientes. Después se crean interfaces VLAN compatibles con Bridge como Parent y se genera un backup nuevo. El caso especial se describe en Comprobar las Bridge VLANs de Sophos Firewall antes de SFOS 22.

STAS

Al actualizar a MR1, la opción Restrict client traffic during identity probe debe estar configurada como No en Authentication > STAS. MR2 corrige el error de MR1 y utiliza No como valor predeterminado en configuraciones nuevas; aun así, deben comprobarse los valores existentes y las reglas basadas en usuarios. Encontrará más información en Configurar STAS en Sophos Firewall.

Escaneo de malware al actualizar a GA Build 411

Solo durante una actualización específica a SFOS 22.0 GA Respin Build 411, NC-177529 puede mostrar temporalmente Malware Unscannable durante la migración, a menudo para www.msftconnecttest.com, porque el nuevo motor de escaneo de Sophos todavía no está disponible. Antes de esta actualización a GA, cambiar de Single engine a Dual engine en Web > General settings y volver al Single Engine utilizado anteriormente una vez finalizada la actualización. Esta medida no se aplica de forma general a MR1, MR2 ni versiones posteriores; Configurar y probar el escaneo de malware en Sophos Firewall explica los antecedentes y la selección del motor de escaneo.

Ventana de mantenimiento y control

• Antes: Descartar bloqueadores, preparar el backup y SSMK, comprobar la sincronización de HA y documentar las rutas de VPN, prueba y reversión.
• Durante: No realizar cambios paralelos en routing, VPN o switching; supervisar el estado y el HA failover.
• Después: Comprobar firmware, interfaces, Internet, reglas de firewall, VPN, NAT, HA, STAS, DNS, DHCP, Central y Log Viewer.

Un túnel en verde o un Policy Test correcto no demuestra que el tráfico de usuario funcione. Por eso, las conexiones críticas deben comprobarse con paquetes reales, Log Viewer, Packet Capture y los valores de Rule ID de las reglas de firewall y NAT. Si hay problemas, no deben modificarse varias áreas al mismo tiempo.

La actualización está completa cuando las pruebas definidas son correctas y se han documentado la versión de destino, el estado de HA, los resultados de las pruebas y las tareas pendientes.

FAQ