Sophos XG vs. XGS: diferencias, EOL y migración

La serie XGS es la sucesora de la serie XG desde 2021. La comparación entre el hardware antiguo y el nuevo ya no se limita al rendimiento. Los últimos modelos XG Series llegaron al End of Life el 31 de marzo de 2025; algunos modelos anteriores ya estaban EOL. Además, SFOS 21.0 y las líneas de firmware posteriores ya no admiten hardware XG ni SG-Series.

Por tanto, la pregunta real ya no es ¿Merece la pena XGS?, sino ¿Cómo se planifica correctamente el cambio desde XG sin pasar por alto routing, VPN, Central Firewall Reporting o sedes remotas?

Respuesta breve

XG y XGS ejecutan ambos Sophos Firewall OS, pero ya no son plataformas equivalentes.

• Lifecycle: XG: End of Life. XGS: plataforma de hardware con soporte activo.
• Firmware: XG: ninguna versión de SFOS desde 21.0. XGS: líneas actuales de SFOS, incluida 22.0.
• Rendimiento: XG: plataforma antigua con menos margen para la inspección moderna. XGS: arquitectura Xstream; la aceleración disponible depende del modelo, firmware y ruta de datos.
• Operación: XG: límite de migración y soporte. XGS: plataforma estándar para nuevos proyectos de hardware.
• Planificación: XG: sustitución necesaria. XGS: sizing, port mapping y transferencia de licencia deben quedar definidos antes del cutover.

Por eso, una XG ya no debería considerarse un modelo de firewall normal, sino una plataforma antigua que debe sustituirse. Para cuestiones de licencia y lifecycle también encaja el calendario Sophos Product Lifecycle.

Qué significa End of Life en la operación de firewall

End of Life en hardware firewall no es una entrada formal en una tabla. Un firewall está en el borde de la red, termina VPNs, filtra tráfico web y de aplicaciones, protege servicios publicados y suele contener configuraciones sensibles. Si esa plataforma deja de mantenerse, surge un riesgo operativo real.

Para una XG productiva, estos puntos son especialmente críticos:

• Ya no pueden usarse nuevas líneas de firmware SFOS.
• Sophos advierte que las actualizaciones de software terminan poco después del EOL; el soporte del fabricante y la sustitución de hardware dejan así de poder planificarse con fiabilidad.
• Nuevas funciones como características actuales de VPN, logging, Health Check o seguridad llegan a plataformas soportadas.
• Licencias, RMA, equipos de sustitución y casos de soporte son más difíciles de planificar.
• Auditorías y ciberseguros pueden valorar críticamente la continuidad operativa de un firewall EOL.

Esto es especialmente crítico en firewalls con Remote Access VPN activo, Site-to-Site VPN, WAF, TLS Inspection, Web Protection, servidores publicados o WebAdmin ampliamente accesible. En esos entornos, mantener una XG operativa solo debería considerarse una solución transitoria limitada, con un plan de migración documentado.

Las tres diferencias más importantes

XG y XGS pueden parecer similares desde fuera según el modelo, pero se diferencian de forma clara técnica y operativamente.

• Lifecycle y firmware: el hardware XG está End of Life. SFOS 21.0, 21.5 y 22.0 ya no admiten hardware XG ni SG-Series. XGS es la plataforma de hardware soportada para las versiones actuales de SFOS.
• Arquitectura y rendimiento: XGS utiliza la arquitectura Xstream y aceleración dependiente del modelo. Aporta más margen para funciones de seguridad actuales, VPN, TLS Inspection, IPS, Web Protection y routing. La ficha técnica del modelo concreto sigue siendo la referencia.
• Migración y operación: el cambio a XGS es un proyecto de migración. Deben revisarse compatibilidad de backups, port mapping, estado de licencias, HA, SD-WAN, Central Firewall Reporting, RED, Access Points y ZTNA gateways.

Arquitectura: Xstream en lugar de la antigua plataforma XG

La serie XGS fue construida para la arquitectura Xstream, especialmente relevante cuando las funciones de protección están activadas. Sin embargo, las rutas de datos aceleradas y los recursos disponibles difieren entre modelos desktop, 1U y 2U; el nombre de la serie no permite deducir por sí solo el throughput. Muchas instalaciones XG antiguas se dimensionaron además con menos TLS Inspection, tráfico cloud, SD-WAN y carga de Remote Access.

Una XGS Appliance aporta, según el modelo, más reservas para:

• IPS, Web Protection y Application Control.
• TLS Inspection y despliegues de certificados/CA más grandes.
• IPsec VPN, SSL VPN, SD-WAN y varios WAN uplinks.
• Más usuarios, sesiones y reglas simultáneos.
• Nuevas funciones de SFOS que ya no están disponibles en XG.

No todas las rutas de datos se vuelven automáticamente más rápidas solo porque se instale una XGS Appliance. Un sizing incorrecto, modelos demasiado pequeños, TLS Inspection mal planificada o una arquitectura VPN poco clara también pueden frenar un firewall nuevo. Para elegir el modelo de destino adecuado, el Sophos Firewall Sizing Guide es más importante que una simple comparación de modelos 1:1.

Cuándo debe sustituirse una XG

La sustitución de una XG no debería planificarse solo cuando una actualización de firmware ya queda bloqueada o un defecto de hardware genera presión. A más tardar con estas señales, corresponde un proyecto de migración:

• El firewall debe actualizarse a SFOS 21.0, 21.5, 22.0 o posterior.
• Existen Remote Access VPN, WAF, servicios accesibles públicamente o varias Site-to-Site VPNs.
• Soporte, auditoría, RMA o renovación de licencia ya no pueden representarse de forma limpia.
• La XG existente está al límite bajo carga de IPS, Web Protection, TLS Inspection o VPN.
• RED, Access Points, SD-WAN, Central Firewall Reporting o ZTNA dependen del firewall existente.
• De todos modos está previsto un HA cluster, rediseño de puertos o cambio de proveedor.

Si una XG todavía está en producción, primero debería documentarse un backup actual, el Secure Storage Master Key y la versión de firmware utilizada. El procedimiento se describe con más detalle en el artículo Crear o restaurar un backup de Sophos Firewall.

Planificar la migración de XG a XGS

En una migración de XG a XGS no debería elegirse solo el modelo aparentemente más cercano. Tiene más sentido hacer un breve inventario antes de la ventana de mantenimiento:

• ¿Qué puertos WAN, LAN y DMZ se usan realmente?
• ¿Hay HA, pilas VLAN, RED, SD-WAN o casos especiales de VPN?
• ¿Qué funciones de seguridad están activas hoy y cuáles deben activarse adicionalmente en el futuro?
• ¿Qué escenarios IPsec, SSL VPN, Sophos Connect o ZTNA están en producción?
• ¿Existe Central Firewall Reporting, administración mediante Sophos Fusion (anteriormente Sophos Central) o SD-WAN Connection Groups?
• ¿Hay Access Points o dispositivos SD-RED vinculados a este firewall?
• ¿Hay rutas estáticas, direcciones IP alias, reglas DNAT o publicaciones WAF que deban estar accesibles inmediatamente después del cambio?
• ¿La plataforma de destino debe volver a ser hardware, o una appliance virtual o cloud?

Definir la ruta de firmware antes del backup

La XG no puede actualizarse a SFOS 21.0 ni 22.0. Sophos distingue el restore según la versión de la XG de origen; en la XGS Appliance de destino, Backup-Restore Assistant requiere SFOS 20.0 MR2 o posterior:

• Con 19.5 MR4 o cualquier versión 20.0, cree directamente el backup y asigne las interfaces durante el restore con Backup-Restore Assistant.
• Con 19.5 MR3 o anterior, la migración es posible, pero el asistente no aparece. Sophos recomienda actualizar primero la XG a 19.5 MR4 o 20.0 MR2 y posterior, siempre que ese paso intermedio siga soportado y sea operativamente aceptable.

El Setup Assistant de la nueva XGS Appliance actualiza el destino a la última versión ofrecida. Si el cambio introduce también SFOS 22, revise la guía de actualización de firmware de Sophos Firewall antes de la ventana de mantenimiento. Una configuración legacy de Remote Access IPsec bloquea las actualizaciones a 22.0 MR1 y posteriores; el legacy CLI VLAN tagging en bridge interfaces bloquea 22.0 MR2 y posteriores, y los backups que lo contienen tampoco pueden restaurarse en 22.0 GA o posterior. SFOS 22 puede requerir además espacio de disco adicional y cambia el comportamiento de las VPN IPsec policy-based.

Recomendación de Avanet: combine el cambio de hardware y un cambio mayor de firmware en una sola ventana únicamente tras superar estas comprobaciones. De lo contrario, un fallo deja sin aclarar si la causa es el backup, port mapping o firmware.

Backup-Restore Assistant y port mapping

El port mapping y Backup-Restore Assistant deben planificarse para los dispositivos exactos de origen y destino: los nombres y el número de puertos, los módulos Flexi Port, las variantes wireless y los modelos de destino no siempre encajan 1:1. Los módulos Flexi Port de XG no son compatibles con XGS y deben sustituirse por módulos XGS adecuados.

En la práctica, conviene preparar una tabla de puertos antes del restore:

• De Port1 a Port1 para LAN: compruebe VLANs, DHCP y DNS.
• De Port2 a Port2 para WAN: compruebe gateway, alias IP y NAT.
• De Port3 a Port4 para DMZ: compruebe Firewall Rules, WAF y DNAT.
• De Flexi Port a un módulo nuevo: compruebe uplink, trunk y compatibilidad del módulo.

El asistente solo muestra puertos físicos. Las interfaces VLAN y alias siguen a su Parent Interface; LAGs y bridges se recrean a partir de los miembros físicos asignados. Las interfaces vinculadas sin asignar pueden convertirse en pseudo ports. Compruebe, además del número de puerto, Zone, IP Assignment, Link Mode, Parent Interface y pertenencia.

Los modelos wireless tienen límites adicionales. Al restaurar un backup XG Wireless o XGS Wireless Gen.1 en un modelo XGS Wireless Gen.2, Sophos exige, entre otras cosas, WPA2 o posterior, ningún TKIP, ninguna interfaz wireless en bridges físicos y un máximo de ocho SSIDs únicos entre LocalWiFi0 y LocalWiFi1. El restore a un modelo sin WLAN integrada requiere eliminar las redes wireless antes del backup. Trate ese cambio como un paso separado y verificado, no como una improvisación durante el cutover.

Si cambia la dirección MAC WAN, routers anteriores o CPEs del proveedor pueden mantener todavía entradas ARP antiguas. Ante esos síntomas ayuda el artículo Resolver un problema ARP de Sophos Firewall después de una migración.

Tratar HA por separado

Un XG-HA-Cluster no se sustituye simplemente mediante restore en dos nuevas XGS Appliances. Si un backup HA se restaura en una XGS Appliance nueva sin HA, el restore no recrea la configuración HA; debe configurarse manualmente. Igualdad de modelo, firmware, licencias, HA Port, monitoring, passphrase, cambio de roles y ventana de prueba requieren un procedimiento separado, por ejemplo Configurar Sophos Firewall High Availability.

Ajustar Sophos Fusion, Reporting, SD-WAN y ZTNA

Después del restore, la nueva XGS Appliance no queda automáticamente integrada igual en todas las funciones de Sophos Fusion. Según el entorno, puede ser necesario:

• registrar el nuevo firewall en Sophos Fusion,
• comprobar Firewall Management y Central Firewall Reporting,
• asignar al dispositivo de sustitución la licencia separada de Central Firewall Reporting y sus datos; los reports locales de XG no se transfieren,
• para SD-WAN Connection Groups, eliminar primero en la XGS Appliance las reglas y túneles creados por Sophos Fusion con prefijo Central_ y después añadirla al grupo,
• cambiar ZTNA gateways al nuevo firewall,
• probar la asignación de SD-RED y Access Points; si la XG sigue conectada en paralelo, eliminar allí la configuración SD-RED y aceptar los Access Points en la XGS Appliance,
• volver a comprobar notificaciones, backups y reports programados.

Para setups de reporting también encaja Activar Central Firewall Reporting. Para evidencias operativas después de la migración, Probar una regla de Sophos Firewall con Log Viewer y Packet Capture y Analizar paquetes descartados en Sophos Firewall son más útiles que una simple prueba de ping.

Errores típicos en migraciones de XG a XGS

Modelo de destino demasiado pequeño

Un modelo sucesor aparentemente adecuado puede ser demasiado pequeño si desde la compra original de la XG se han añadido más usuarios, más VPNs, más TLS Inspection, más Web Protection o más ancho de banda. Por eso no debería compararse solo modelo XG contra modelo XGS, sino considerar carga real, funciones de protección activas y crecimiento.

Port mapping revisado solo de forma superficial

Si LAN, WAN, DMZ, VLAN trunks, HA ports o conexiones del proveedor se conectan de otra forma, un restore correcto no es suficiente. Después del restore deben comprobarse de forma específica zonas de interfaces, gateways, rutas SD-WAN, reglas NAT, reglas WAF y Firewall Rules.

Firmware antiguo o backup desactualizado

Un backup muy antiguo aumenta el riesgo de que interface mapping, certificados, VPNs o configuraciones especiales migren de forma inesperada. Antes del cambio, el firewall antiguo debería llevarse, en la medida en que todavía tenga sentido y soporte, a un estado adecuado y se debería crear un backup nuevo.

Sistemas posteriores olvidados

Muchas migraciones no fallan por el restore, sino por sistemas dependientes: monitoring, Syslog, SIEM, correos de backup, clientes VPN, ARP del proveedor, DNS, DHCP, RED, Access Points o Sophos Fusion. Estos puntos pertenecen a la checklist, no a la búsqueda de errores después del cambio.

Checklist antes del cambio

• Firmware actual de la XG y firmware de destino de la XGS Appliance documentados.
• Compatibilidad de restore de los modelos exactos de origen y destino verificada en la herramienta de Sophos.
• Backup actual creado y contraseña de restore guardada de forma segura.
• Secure Storage Master Key actual y, si corresponde, anterior, además de la contraseña del backup, disponibles de forma segura y separada.
• Port mapping preparado para WAN, LAN, DMZ, VLAN trunks y HA.
• Flexi Ports XG sustituidos por módulos XGS compatibles; restricciones wireless comprobadas.
• Transferencia de licencia, registro en Sophos Fusion y estado de soporte comprobados.
• Para SFOS 22: legacy IPsec, CLI VLAN tagging, espacio de disco y VPN IPsec policy-based comprobados.
• VPNs, NAT, WAF, SD-WAN, DHCP, DNS y routing preparados como lista de pruebas.
• RED, Access Points, ZTNA, Central Firewall Reporting y monitoring considerados.
• Plan de rollback con equipo antiguo, plan de cableado y ventana de mantenimiento definido.
• Contactos para proveedor, DNS, monitoring y aplicaciones disponibles.

Rollback con un umbral de aborto claro

Mantenga la XG antigua sin cambios, apagada o físicamente aislada, y disponible con un plan de cableado etiquetado hasta la aceptación. Antes del cutover, defina una hora y criterios de aborto medibles: WAN Gateway inaccesible, publicación DNAT crítica caída o túnel VPN esencial todavía down tras el periodo reservado para diagnóstico.

Para el rollback, aísle la XGS Appliance, devuelva el cableado a la XG según el plan y solo entonces encienda la XG. Vuelva a comprobar WAN, routing, VPN y servicios publicados. Los cambios realizados durante la prueba de la XGS Appliance no están automáticamente en la XG antigua; regístrelos y evalúelos después del rollback. No resetee ni retire la XG hasta que la XGS Appliance se haya aceptado como estable, tenga backup y esté documentada.

Comprobación después de la migración

Después del cambio no basta con comprobar si internet funciona. Una migración limpia solo está completa cuando se han validado las funciones operativas más importantes:

• Comprobar dashboard, estado de licencia, registro en Sophos Fusion y correo de backup.
• Probar WAN gateway, direcciones IP alias, NAT y servicios publicados.
• Comprobar Site-to-Site VPN, Remote Access VPN y perfiles de Sophos Connect.
• Controlar rutas SD-WAN, rutas estáticas y Route Precedence.
• Probar Firewall Rules con logging.
• Comprobar por muestreo IPS, Web Protection, TLS Inspection y Application Control.
• Controlar conexiones RED y Access Point.
• Probar Syslog, Central Firewall Reporting, notificaciones y monitoring.
• Retirar la XG antigua solo después de una fase operativa estable.

Si inmediatamente después de la migración algunos destinos no son accesibles, se debería trabajar sistemáticamente con Log Viewer, Packet Capture y routing checks. Para el diagnóstico básico ayudan Usar Sophos Firewall Packet Capture en WebAdmin y Cambiar Route Precedence en Sophos Firewall de forma segura.

FAQ