Sophos Firewall v22 MR2: novedades, correcciones y actualización

Sophos publicó Sophos Firewall OS 22.0 MR2 Build 546 el 14 de julio de 2026. Este Maintenance Release es más pequeño que una versión principal, pero ofrece bastante más que un simple paquete de correcciones: incorpora control de Post-Quantum Cryptography, una detección más precisa de aplicaciones de IA generativa, una nueva extensión para Chromebook, una configuración predeterminada de STAS menos disruptiva y cadenas de confianza de Let’s Encrypt actualizadas. Al mismo tiempo, Sophos corrige 53 problemas documentados en firewall, HA, IPsec, autenticación, logging, WAF, reporting y otros componentes.

MR2 es, ante todo, una versión orientada a la operación y la estabilidad. Las nuevas funciones son interesantes, pero en muchos entornos productivos los fallos de kernel, las causas de Failsafe, los problemas de HA y los errores de VPN corregidos serán el motivo más importante para actualizar.

Detectar y controlar Post-Quantum Cryptography

La novedad de seguridad más destacada afecta a Post-Quantum Cryptography (PQC). Se trata de métodos criptográficos diseñados para resistir ataques de futuros ordenadores cuánticos suficientemente potentes. El riesgo actual no consiste únicamente en que algún día exista un equipo de este tipo. Para datos especialmente sensibles ya es relevante el principio Harvest now, decrypt later: se captura y almacena tráfico cifrado para descifrarlo más adelante con tecnología más potente.

SFOS 22.0 MR2 detecta intercambios de claves puros e híbridos basados en ML-KEM. El National Institute of Standards and Technology estandarizó el método en 2024 como FIPS 203; se basa en el problema matemático Module Learning With Errors. NIST define tres conjuntos de parámetros, ML-KEM-512, ML-KEM-768 y ML-KEM-1024, con distintas características de seguridad y rendimiento.

ML-KEM no cifra directamente el tráfico web posterior. Es un Key Encapsulation Mechanism que permite establecer un secreto compartido entre cliente y servidor a través de un canal público. A partir de ese secreto se derivan después las claves de sesión simétricas con las que se cifran y autentican los datos de forma eficiente.

En un intercambio de claves PQC puro, la seguridad de la negociación depende únicamente del método poscuántico. Las implementaciones TLS actuales suelen utilizar métodos híbridos, en los que ML-KEM se combina con un método clásico como X25519. El objetivo de una negociación híbrida correctamente diseñada es mantener protegida la sesión mientras al menos uno de los dos componentes siga siendo seguro. Sin embargo, esta es una propiedad de la combinación concreta y no está garantizada automáticamente para cualquier método híbrido. El enfoque reduce el riesgo de depender por completo de un procedimiento criptográfico relativamente nuevo durante una fase temprana de migración.

Sophos ya publica los nombres de los patrones detectados: TLS 1.3 PQC ML-KEM-512, ML-KEM-768, ML-KEM-1024, X25519 ML-KEM-768 y Hybrid Key Share. Los ID concretos de las firmas IPS siguen sin estar documentados públicamente.

Detección y control de políticas mediante IPS

En TLS 1.3, el cliente anuncia los grupos de intercambio de claves compatibles en el ClientHello. Estos metadatos se transmiten antes de establecer la sesión cifrada de la aplicación. Por ello, el IPS puede identificar en principio el uso de un método PQC o híbrido durante la negociación TLS sin tener que descifrar posteriormente el contenido HTTP.

Sophos proporciona nuevos patrones IPS para ello. Para que se evalúen, debe estar activa la IPS Protection, debe existir una licencia válida de Network Protection y la política IPS correspondiente debe estar asignada a una regla de firewall. Dentro de una política propia se pueden definir acciones como:

permitir,
registrar,
descartar paquetes individuales o toda la sesión,
finalizar la sesión TCP mediante un reset, o
desactivar la firma.

Las firmas PQC introducidas en MR2 están desactivadas de forma predeterminada. Es una decisión razonable, ya que navegadores, plataformas cloud, CDN y bibliotecas TLS actuales utilizan cada vez más métodos PQC híbridos de forma habitual. Si Sophos entregara de inmediato estas firmas con una acción de bloqueo predeterminada, podría interrumpir conexiones web y API legítimas. En el primer hilo de comentarios, Sophos también justifica esta configuración por la creciente difusión de PQC-TLS y el riesgo de generar un gran número de alertas innecesarias.

Yo no activaría inmediatamente las nuevas firmas en modo de bloqueo. Es preferible crear una política IPS separada para un grupo de prueba limitado y, al principio, registrar únicamente las detecciones. Después se puede revisar en Log Viewer qué navegadores, aplicaciones y destinos utilizan ML-KEM. Solo cuando esté claro qué política criptográfica se quiere aplicar y qué servicios legítimos podrían verse afectados, recurriría a Drop session o Reset. PQC no es automáticamente sospechoso: en la mayoría de los casos, una detección solo indica que una aplicación ya utiliza métodos TLS modernos.

Control de la negociación TLS mediante Web Protection

Además del IPS, Web Protection interviene directamente en la negociación TLS permitida. Sophos indica que las sesiones web no pueden negociar algoritmos PQC que el firewall no admita. Esta función es distinta de la detección del IPS: el IPS clasifica la negociación visible y aplica una acción de política, mientras que Web Protection debe garantizar que una sesión web protegida solo se establezca con un método criptográfico compatible con la ruta de procesamiento de SFOS.

Esto es especialmente importante con TLS Inspection. En ese caso, el firewall no se limita a observar el flujo de datos, sino que debe terminar la sesión TLS, comprobar o volver a emitir certificados y negociar parámetros criptográficos compatibles en ambos lados. Por tanto, un algoritmo compatible con el navegador y el servidor de destino no tiene por qué serlo también con cada Inspection Engine intermedia.

El intercambio de claves PQC también modifica técnicamente la negociación TLS. Los Key Shares híbridos son mayores que los valores X25519 clásicos y pueden hacer que un ClientHello se reparta entre varios paquetes. Estas conexiones son válidas según TLS, pero pueden exigir mucho más a Middleboxes, proxies o Inspection Engines antiguas. Por eso, el soporte de MR2 no es solo una firma adicional, sino también una adaptación de compatibilidad para una pila TLS que está cambiando.

Sophos no documenta en detalle si Web Protection finaliza la sesión cuando encuentra un método PQC no compatible, si la negociación vuelve a un método clásico o si la reacción varía según la ruta de datos. Por ello, no debe deducirse un comportamiento de fallback concreto a partir del anuncio. Lo que sí está claro es que una negociación PQC no compatible no debe atravesar la capa de protección sin control.

Después de la actualización, los entornos con TLS Inspection deberían probar especialmente estos puntos:

Probar versiones actuales de Chrome, Edge, Firefox y Safari con los servicios SaaS y cloud más utilizados.
Acceder a los mismos destinos una vez mediante una regla con TLS Inspection y otra sin ella.
Comprobar excepciones de TLS Inspection, errores de certificados y páginas de bloqueo.
Revisar los logs de IPS y Web Protection en busca de nuevos mensajes PQC, errores de handshake y resets.
Probar por separado aplicaciones críticas con bibliotecas TLS propias, clientes API o runtimes Java.
Si aparecen problemas, utilizar Packet Capture para determinar si falla ya el handshake TLS o si se interrumpe después la sesión protegida de la aplicación.
Solo entonces decidir si se necesita una acción explícita Allow, Drop o Reset.

IA generativa con Synchronized Application Control

MR2 mejora la categorización de aplicaciones de IA generativa. La limitación decisiva ya aparece en el nombre de la función: la visibilidad adicional procede de Synchronized Application Control. Sophos Endpoint detecta las aplicaciones localmente y comparte esta información con el firewall mediante Security Heartbeat. A continuación, SFOS puede asignar la aplicación con mayor precisión en reporting y en las reglas de Application Control.

Esto ayuda con aplicaciones que se comunican mediante protocolos web generales, CDN compartidas o destinos cambiantes y que resultan difíciles de identificar de forma inequívoca solo con firmas clásicas de firewall. Una categoría más precisa facilita, por ejemplo, diferenciar entre aplicaciones web normales y herramientas GenAI, así como analizar qué usuarios o dispositivos las utilizan.

Sin embargo, la función no es un CASB universal ni un sistema DLP. No analiza automáticamente el contenido confidencial de los prompts y, sin un Sophos Endpoint compatible, no ofrece la misma visibilidad de aplicaciones. En entornos con Microsoft Defender o endpoints mixtos siguen siendo relevantes los controles DNS, web, TLS, proxy o SSE/CASB.

Una política útil requiere, por tanto, algo más que la nueva categoría:

Sophos Endpoint y Security Heartbeat deben estar conectados correctamente.
Las aplicaciones desconocidas deben clasificarse regularmente en Synchronized Application Control.
Las reglas de firewall necesitan una política de Application Control adecuada y logging activado.
Deben definirse los servicios GenAI permitidos, las cuentas corporativas y las normas de protección de datos.
Los datos sensibles requieren controles adicionales de DLP, navegador, endpoint o SaaS.

Bloquear todas las aplicaciones GenAI rara vez es la mejor primera medida. Resulta más útil aplicar una política gradual: permitir servicios corporativos aprobados, registrar o bloquear servicios desconocidos o no verificados y evaluar el uso en función de las necesidades reales del negocio.

El procedimiento práctico para el grupo piloto, el Application Filter, el bloqueo y la validación se explica en Detectar y controlar la IA generativa con Sophos Firewall.

Autenticación: Chromebook, STAS y eDirectory

MR2 modifica tres áreas técnicamente distintas de la identificación de usuarios. En el trabajo diario todas afectan al mismo punto crítico: que el firewall identifique de forma fiable al usuario y le asigne la política correcta.

Chromebook User ID con Manifest V3

La nueva Sophos Chromebook User ID Extension es compatible con Chrome Manifest V3. Manifest V3 es la plataforma actual de extensiones de Chrome y modifica, entre otras cosas, los permisos, los procesos en segundo plano y la forma en que las extensiones procesan eventos de red. Sin esta nueva versión, la extensión anterior de Sophos dejaría de recibir actualizaciones regulares a largo plazo.

Según Sophos, no se contempla una actualización In-place. La extensión antigua debe desinstalarse y sustituirse por la nueva. En entornos Chromebook administrados, el cambio debe realizarse en Google Admin Console o en la solución de Endpoint Management utilizada:

Eliminar la antigua Sophos Chromebook User ID Extension de la instalación forzada.
Añadir la nueva versión Manifest V3 y asignarla a los grupos de destino.
Iniciar sesión con un usuario de prueba.
Comprobar en el firewall que el nombre de usuario y la dirección IP se asignan correctamente.
Activar una política web o de firewall basada en usuario y comprobar el resultado en Log Viewer.

El orden es importante. Si se elimina la extensión antigua antes de distribuir la nueva, la asignación de usuarios se perderá temporalmente. Las reglas podrían entonces aplicar una política de fallback más general o bloquear el acceso.

La configuración completa de Device Access, certificado, reglas de firewall, política JSON y API Controls se explica en Configurar Chromebook SSO con Google Workspace.

STAS ya no bloquea de forma predeterminada durante la comprobación de identidad

Con Sophos Transparent Authentication Suite (STAS), el firewall consulta qué usuario de Active Directory se encuentra detrás de una dirección IP cuando detecta un cliente nuevo o modificado. La opción Restrict client traffic during identity probe determina si el cliente puede enviar tráfico durante esa comprobación.

MR2 cambia el valor predeterminado a No. El tráfico puede continuar mientras el firewall compara el usuario y la dirección de destino. Esto reduce pequeñas interrupciones que pueden resultar especialmente visibles en sesiones nuevas, cambios de usuario, roaming o respuestas lentas de STAS Collector.

La mejora de comodidad implica una contrapartida: durante la comprobación, el firewall debe trabajar con el contexto de identidad disponible en ese momento. En entornos con reglas basadas en usuario muy estrictas conviene comprobar qué política se aplica durante ese breve intervalo. Tras la actualización no se debe asumir que las configuraciones existentes adoptan automáticamente el mismo valor. Hay que verificar el valor actual, el comportamiento deseado y los logs reales.

Novell eDirectory termina con SFOS 23.0

MR2 también muestra un aviso End-of-Life para Novell eDirectory Authentication Server. El soporte finalizará con SFOS 23.0. eDirectory sigue funcionando en MR2; el mensaje es una advertencia previa, no una retirada inmediata de la función.

No echaremos de menos esta integración. Ninguno de nuestros clientes utiliza ya Novell eDirectory y hace tiempo que dejó de tener relevancia en proyectos nuevos. Los pocos entornos que todavía lo utilicen disponen de tiempo hasta SFOS 23.0 para migrar a una fuente de identidad compatible. Además del Authentication Server, deben revisarse los grupos importados, las reglas de firewall, los permisos VPN, las políticas web, Captive Portal y los informes basados en usuarios.

La guía Migrar eDirectory antes de SFOS 23 explica cómo migrar de forma controlada la fuente de identidad de destino, los grupos y los servicios, y conservar una vía de reversión.

Let’s Encrypt y la gestión de certificados

SFOS 22.0 MR2 actualiza la compatibilidad con nuevos certificados raíz e intermedios de Let’s Encrypt. Ahora se admiten las cadenas YE Root, YE1, YE2, YR Root, YR1 y YR2. Sophos Firewall queda así preparado para la emisión y renovación automáticas de certificados mediante las cadenas actuales y futuras de Let’s Encrypt.

Esto es relevante porque una solicitud ACME correcta no basta por sí sola. El firewall, el sistema remoto y los clientes también deben poder construir y validar correctamente la cadena del certificado emitido. De lo contrario, Trust Stores obsoletos pueden provocar errores de certificado aparentemente inexplicables aunque el certificado Leaf sea válido.

Además, las notificaciones por correo de Let’s Encrypt incluyen ahora el hostname y el número de serie del firewall. En entornos con varias appliances resulta más sencillo identificar qué dispositivo ha generado una renovación, un error u otro mensaje sobre certificados. El número de serie forma parte, no obstante, de los datos de inventario del dispositivo; las notificaciones solo deben enviarse a destinatarios y buzones controlados.

Después de la actualización conviene realizar una prueba completa de certificados:

Comprobar el estado ACME y la próxima fecha de renovación.
Verificar el hostname, la resolución DNS y la accesibilidad del Challenge.
Validar la cadena de certificados en el navegador o mediante una prueba TLS externa.
Revisar por separado los certificados de WAF, WebAdmin, User Portal y VPN.
Comprobar la recepción de la nueva notificación por correo y la lista de destinatarios.

Config Studio 2.6 amplía el análisis y la migración

Junto con MR2, Sophos destaca Firewall Config Studio 2.6. La herramienta se ejecuta en el navegador fuera del firewall y, por tanto, no es una función WebAdmin integrada en Build 546. Sin embargo, complementa la operación precisamente donde SFOS sigue ofreciendo posibilidades limitadas de análisis y comparación.

Las funciones más importantes de la versión 2.6 son:

Merge templates: permite combinar una configuración base con una plantilla específica de un sector o caso de uso. Acelera los despliegues estandarizados, pero no sustituye la revisión de objetos, interfaces o reglas en conflicto.
Enhanced Global Search: permite buscar objetos globalmente y abrir directamente el lugar donde se utilizan. Resulta especialmente útil en configuraciones extensas y para depurar dependencias poco claras.
Improved Configuration Report: las reglas de firewall, NAT y TLS muestran no solo los nombres de los objetos referenciados, sino también sus valores y detalles. Esto facilita las revisiones sin tener que consultar cada objeto por separado.
Migration Insights: después de una conversión, Config Studio muestra el porcentaje migrado correctamente. Es un valor orientativo, no una validación final: las VPN, la autenticación, los certificados y las funciones específicas de cada fabricante que no se hayan transferido deben revisarse manualmente.
Multi-file Configuration Diff: permite comparar varios estados de configuración para identificar entre qué backups apareció un cambio, un error o una desviación no deseada.
Compatibilidad de Backup Restore: ayuda a comprobar si un backup puede restaurarse en otro modelo de Sophos Firewall.
Referencia de Flexi Ports y velocidad de puertos: permite comparar layouts de puertos, módulos Flexi y velocidades compatibles de hasta 25, 40 o 100 Gbit/s antes de una migración de hardware.

Config Studio 2.6 se analiza en detalle en Sophos Firewall Config Studio 2.6: migración integrada. El flujo de trabajo práctico para Report, Compare, Editor y una reimportación controlada se describe en Utilizar Sophos Firewall Config Studio.

Los 53 problemas corregidos en Build 546

Sophos menciona más de 50 correcciones de estabilidad, fiabilidad y seguridad. La siguiente clasificación incluye los 53 ID de las Release Notes oficiales. La lista no sustituye una evaluación individual del soporte, pero muestra qué función estaba afectada y por qué la corrección es relevante para la operación.

Firewall, kernel, HA y estabilidad del sistema

NC-180331 – Gestión incorrecta de memoria en algif_aead y algif_skcipher: corrige una vulnerabilidad del kernel de Linux en componentes criptográficos.
NC-181331 – Una partición de configuración llena ponía el firewall en Failsafe: reduce el riesgo de interrupción por falta de espacio de configuración.
NC-180974 – Un fallo de kernel en sdwan_profile activaba un failover de HA: estabiliza entornos SD-WAN y evita cambios de rol innecesarios en el clúster.
NC-178354 – Fallo de kernel al evaluar reglas SD-WAN: evita caídas durante el matching de reglas SD-WAN.
NC-178413 – Un valor vacío en Services provocaba un error de ipset y Failsafe: gestiona con mayor robustez objetos de servicio dañados o incompletos.
NC-177934 – El firewall entraba en Failsafe tras actualizar a SFOS 22.0 GA: corrige una consecuencia directa de actualización en builds anteriores de v22.
NC-177441 – El dispositivo HA primario inicial entraba en Failsafe tras actualizar a SFOS 22.0 GA: mejora la estabilidad de arranque del nodo primario.
NC-177467 – El dispositivo Auxiliary no arrancaba debido a muchas conexiones SSH simultáneas sin autenticar: importante para sistemas HA expuestos o sometidos a numerosos escaneos; esta corrección se vigila especialmente en los primeros comentarios sobre XGS 5500 HA.
NC-173031 – Las Application Policies importadas no se sincronizaban automáticamente con el dispositivo Auxiliary: garantiza políticas más coherentes en ambos nodos HA.
NC-177536 – La actualización a SFOS 22.0 GA fallaba en el dispositivo HA primario: estabiliza la ruta de actualización en clústeres HA.
NC-178745 – Un dispositivo HA se reiniciaba automáticamente por Out-of-Memory: reduce reinicios no planificados causados por el área de logging.
NC-180110 – El dispositivo HA primario entraba en Failsafe porque no se iniciaba el Logging Daemon: evita que un fallo de inicio del logging deje fuera de servicio todo el nodo primario.
NC-180933 – Los administradores no podían iniciar sesión en WebAdmin Console: corrige la pérdida directa de acceso administrativo a la interfaz.
NC-177769 – El servicio eBPF dejaba de responder tras una actualización de patrones: estabiliza la ruta de datos acelerada después de actualizar firmas.
NC-180152 – Las actualizaciones de interfaces tardaban más en SFOS 22.0 GA que en 21.5: reduce los retrasos al aplicar cambios de interfaces.
NC-179462 – Advertencias repetidas al leer estadísticas de hardware: elimina ruido innecesario de los logs en appliances XGS.

Reglas de firewall, tráfico de usuarios y routing

NC-181741 – El tráfico de usuarios no autenticados se descartaba cada hora: evita interrupciones periódicas en entornos con tráfico no autenticado.
NC-178903 – Los usuarios SATC perdían el acceso a Internet tras actualizar a SFOS 22.0 GA: restablece el acceso basado en usuario con Sophos Authentication Thin Client.
NC-178141 – Local ACL descartaba determinados mensajes de error ICMP tras la actualización GA: mejora Path MTU Discovery y el diagnóstico de errores que dependen técnicamente de ICMP.
NC-178197 – El tráfico de aplicaciones se detenía temporalmente con una Bandwidth Policy basada en aplicaciones: estabiliza QoS en reglas que controlan el ancho de banda según la aplicación detectada.
NC-180226 – La interfaz no mostraba un error al duplicar una dirección MAC en Spoof protection trusted MAC: evita configuraciones erróneas silenciosas en la lista de excepciones de Spoof Protection.
NC-181299 – La base de datos GeoIP asignaba una IP al Reino Unido en lugar de Alemania: corrige la asignación de país para reglas e informes GeoIP.

IPsec y VPN

NC-180433 – El multicast a través de un túnel VPN provocaba fallos repetidos del firewall: importante para routing, streaming o Discovery mediante multicast sobre IPsec.
NC-178121 – Las conexiones Site-to-Site IPsec quedaban en una posición incorrecta del grupo de failover tras usar Drag and Drop: garantiza que se conserve la prioridad configurada de los túneles.
NC-171719 – Problema de routing SD-WAN con tráfico ESP: mejora la selección de ruta para IPsec/ESP nativo en escenarios SD-WAN.
NC-180520 – El gateway XFRM quedaba inaccesible con aceleración IPsec, Alias IP y entrada ESP por otro puerto WAN: corrige un caso especial complejo de Multi-WAN con túneles IPsec acelerados.
NC-176855 – Bajo rendimiento IPv6 a través de IPsec basado en rutas: mejora el rendimiento IPv6 en diseños VPN basados en túneles.
NC-181687 – La creación de una política SSL VPN terminaba con un Internal Server Error: restablece la creación de políticas en la nueva arquitectura Control Plane/HA.
NC-175860 – Remote Access IPsec dejaba de funcionar tras un failover HA si se había regenerado el Appliance Certificate: estabiliza conexiones Remote Access basadas en certificados durante cambios de rol.

Autenticación, Central y gestión de configuración

NC-180824 – Los nuevos usuarios AD de un grupo AD secundario no podían iniciar sesión en VPN Portal: corrige la evaluación de pertenencias a grupos secundarios o anidados.
NC-176806 – Microsoft Entra ID SSO fallaba por falta de Intermediate CAs: mejora la validación de certificados al iniciar sesión con Entra ID.
NC-160157 – Last access time se conservaba tras borrar un usuario y aparecía en el usuario nuevo: evita datos históricos engañosos al volver a crear una cuenta.
NC-181175 – El Group Policy Push desde Sophos Central quedaba en pending y no se aplicaba: corrige cambios de grupo bloqueados en la gestión centralizada.
NC-180513 – La importación de configuración desde la vista de Sophos Central no funcionaba después de actualizar a MR1: restablece la importación basada en Central.
NC-181904 – Los correos en cuarentena no podían liberarse desde Sophos Central: corrige este flujo de trabajo; WebAdmin local era antes la solución práctica.

Después de la actualización conviene seguir revisando la Central Firewall Task Queue. Corregir un error del producto no garantiza que desaparezcan automáticamente tareas antiguas bloqueadas o estados de grupo incoherentes.

Logging y reporting

NC-181520 – Log Viewer era demasiado lento: mejora el tiempo de respuesta durante búsquedas y diagnósticos.
NC-172912 – System Graph parpadeaba: estabiliza la visualización de métricas del sistema.
NC-172020 – Los firewalls sin On-box Reporting enviaban PDF vacíos del Traffic Dashboard: evita informes diarios sin contenido.
NC-169646 – Los PDF On-demand mostraban gráficos y tablas incorrectos en Chrome: corrige la generación de informes en el navegador.
NC-155252 – Un Disk I/O elevado provocaba picos de CPU y cortes de Internet de hasta un minuto: una corrección de estabilidad especialmente relevante para sistemas con uso intensivo de reporting y logging.

NC-178745 y NC-180110, incluidos en la sección de estabilidad, también afectan al Logging Framework, pero repercutían directamente en toda la appliance mediante reinicios o Failsafe.

Correo electrónico, antivirus y Security Heartbeat

NC-180066 – Las actualizaciones de patrones SAVI y AVIRA fallaban y detenían el servicio antivirus: garantiza que un error de patrones no termine todo el servicio AV.
NC-177930 – Los correos quedaban en el spool por un fallo de mailpoller: evita el bloqueo de la entrega en modo MTA.
NC-171602 – Las notificaciones del firewall no superaban la verificación DKIM: mejora la entrega de correos del sistema firmados.
NC-176012 – Se notificaba la ausencia de Heartbeat cuando dos endpoints utilizaban la misma docking station o interfaz USB: reduce falsas alertas de Heartbeat con dispositivos alternos en hardware compartido.

Quienes utilicen MTA Mode deberían probar después de la actualización el Mail Spool, la cuarentena, DKIM y la liberación desde Central siguiendo los pasos de Sophos Firewall Mail Protection en MTA Mode.

WAF, Web Protection y RED

NC-180200 – WAF se detenía en Home Edition durante la sincronización nocturna de licencias: evita interrupciones periódicas de WAF en instalaciones Home Edition.
NC-177457 – Con WAF Debugging activado, la contraseña aparecía visible en reverseproxy.log: corrige la exposición de texto claro en el Debug Log. Aun así, deben revisarse y protegerse o eliminarse conforme a las normas los logs antiguos.
NC-176788 – ResponseFieldSize volvía al valor predeterminado al cambiar el certificado de una regla WAF: conserva el límite de tamaño configurado deliberadamente.
NC-167019 – Snort provocaba una carga elevada de CPU con tráfico Veeam sin excepción: reduce los picos de carga durante backups; las excepciones existentes deben revisarse para comprobar si siguen siendo necesarias.
NC-178906 – El firewall entraba en Failsafe con Failed to start Red server service: estabiliza el servicio RED Server y evita un estado Failsafe de toda la appliance.

Firmware, DDNS e interfaz de usuario

NC-170200 – Varios intentos de actualización en pocos minutos hacían fallar Firmware Upgrade: hace más robusto Firmware Management; aun así, deben evitarse inicios paralelos o repetidos de forma precipitada.
NC-180219 – Cloudflare DDNS no funcionaba tras actualizar a SFOS 22.0 MR1: restablece las actualizaciones DNS dinámicas para Cloudflare.
NC-181575 – El campo de hora de Schedules se mostraba incorrectamente: evita interpretaciones erróneas al editar reglas programadas.
NC-171424 – Tras borrar la única Exception de la última página, la lista Web Exceptions aparecía vacía: vuelve correctamente a la página anterior en lugar de mostrar una configuración aparentemente vacía.

Planificar la actualización y validar MR2

Sophos admite la actualización a v22 MR2 desde todas las versiones compatibles de las series v21.5, v21 y v20. La imagen de firmware puede descargarse manualmente desde Sophos Central; la distribución automática a dispositivos conectados se realizará gradualmente durante las próximas semanas. Según Sophos, la actualización está disponible sin costes adicionales de firmware para firewalls con soporte Enhanced o Enhanced Plus.

A pesar de la extensa lista de correcciones, MR2 no debe desplegarse sin pruebas en todos los sistemas al mismo tiempo. El hilo público de comentarios se abrió el mismo día de la publicación. Los primeros mensajes preguntan especialmente por la estabilidad del XGS 5500 en Active-Passive HA y por la corrección NC-177467. Esto no confirma un nuevo error de MR2, pero sí es un buen motivo para actualizar los sistemas HA y las ubicaciones críticas de forma gradual.

Antes de la actualización

Comprobar la ruta de actualización compatible y el estado de la licencia.
Crear un backup completo y cifrado, y guardarlo externamente.
Realizar el SFOS 22 Upgrade Check.
Evaluar los findings abiertos del Sophos Firewall Health Check.
Comprobar el estado de HA, los SSD, las particiones libres y el estado de patrones.
Documentar las funciones críticas: WAN, SD-WAN, IPsec, SSL VPN, WAF, MTA, DDNS, autenticación y Central Management.
Preparar la ventana de mantenimiento, el acceso a la consola local y los criterios de rollback.

Después de la actualización

Comprobar el build 22.0 MR2 546, el estado del sistema y los Hotfixes activos.
En HA, revisar ambos nodos, la sincronización, los roles y el failover.
Probar WAN, DNS, DHCP/DDNS, SD-WAN y el acceso a Internet.
Comprobar VPN Site-to-Site y Remote Access, incluidos IPv6 y failover.
Validar AD, Entra ID, STAS, SATC y el inicio de sesión en portales con usuarios de prueba.
Revisar WAF, Let’s Encrypt, MTA, cuarentena y notificaciones.
Comprobar Central Task Queue y los últimos cambios de grupo aplicados.
Buscar en Log Viewer nuevos errores, indicios de Failsafe, reinicios de servicios y mensajes PQC.
Actualizar más appliances solo después de un periodo de observación estable.

El proceso completo de backup, ventana de mantenimiento y comprobaciones posteriores se describe en Preparar la actualización de firmware de Sophos Firewall.

Conclusión

Sophos Firewall v22 MR2 es un Maintenance Release recomendable con una combinación inusualmente amplia. Post-Quantum Cryptography y la mejor categorización de GenAI muestran hacia dónde evolucionan el control de red y de aplicaciones. Chromebook Manifest V3, STAS y Let’s Encrypt son menos espectaculares, pero resuelven problemas concretos de ciclo de vida y operación.

El motivo más importante para instalar Build 546 sigue siendo la estabilidad: se han corregido varios fallos de kernel, estados Failsafe, problemas de HA y VPN, una contraseña en texto claro en el Debug Log de WAF y fallos relevantes de logging, reporting, antivirus y correo. Precisamente por la profundidad de estos cambios, la actualización no debe tratarse como un simple clic rutinario. El backup, el despliegue gradual y una comprobación específica de funciones siguen siendo imprescindibles.