Sophos XG vs. XGS: diferencias, EOL y migración
La serie XGS es la sucesora de la serie XG desde 2021. Pero la comparación original entre hardware antiguo y nuevo hoy ya no es solo una cuestión de rendimiento. El hardware Sophos XG está End of Life desde el 31 de marzo de 2025. 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 Reporting o sedes remotas?
Respuesta breve
XG y XGS ejecutan ambos Sophos Firewall OS, pero ya no son plataformas equivalentes.
| Tema | XG | XGS |
|---|---|---|
| Lifecycle | End of Life | plataforma de hardware con soporte activo |
| Firmware | sin soporte para SFOS 21.0/21.5/22.0 | versiones actuales de SFOS |
| Rendimiento | plataforma más antigua, menos reservas para inspección moderna | arquitectura Xstream con más reservas |
| Operación | riesgo de migración y límite de soporte | plataforma estándar para proyectos nuevos |
| Planificación | sustitución necesaria | planificar correctamente sizing, port mapping y transferencia de licencia |
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. Una 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.
- Las actualizaciones de seguridad, Hotfixes y el soporte del fabricante están limitados o dejan de estar disponibles.
- 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 con funciones de aceleración dedicadas. Esto aporta más reservas para funciones de seguridad actuales, VPN, TLS Inspection, IPS, Web Protection y routing.
- 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 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. En el día a día, esto no es solo un término de marketing, sino algo relevante sobre todo cuando las funciones de protección están activadas. Muchas instalaciones XG antiguas se dimensionaron originalmente cuando había menos TLS Inspection, menos tráfico cloud, menos SD-WAN y menos carga de Remote Access.
Una XGS 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. 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:
- La 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 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, Sophos Central Management o SD-WAN Connection Groups?
- ¿Hay Access Points o dispositivos SD-RED vinculados a esta 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?
Backup-Restore Assistant y port mapping
El Migration Center para migraciones de XG a XGS es la referencia externa más importante para port mapping y Backup-Restore Assistant. Esto es importante porque los nombres de puertos, el número de puertos, los módulos Flexi Port, los modelos Wireless y los modelos de destino no siempre encajan 1:1.
En la práctica, conviene preparar una tabla de puertos antes del restore:
| Dispositivo antiguo | Dispositivo nuevo | Finalidad | Comprobación |
|---|---|---|---|
| Port1 | Port1 | LAN | VLANs, DHCP, DNS |
| Port2 | Port2 | WAN | Gateway, alias IP, NAT |
| Port3 | Port4 | DMZ | Firewall Rules, WAF, DNAT |
| Flexi Port | nuevo módulo | Uplink o trunk | compatibilidad del módulo |
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 nuevos dispositivos XGS. HA debe planificarse conscientemente de nuevo: igualdad de modelo, estado de firmware, licencias, HA-Port, monitoring, passphrase, cambio de roles y ventana de prueba. Los detalles pertenecen a la planificación de HA, por ejemplo con Configurar Sophos Firewall High Availability.
Ajustar Central, Reporting, SD-WAN y ZTNA
Después del restore, la nueva XGS no queda automáticamente integrada igual en todas las funciones de Sophos Central. Según el entorno, puede ser necesario:
- registrar la nueva firewall en Sophos Central,
- comprobar Firewall Management y Central Reporting,
- controlar la licencia de Central Firewall Reporting y la asignación de datos,
- reasignar SD-WAN Connection Groups,
- cambiar ZTNA gateways a la nueva firewall,
- probar la asignación de RED y Access Points,
- 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 Central. 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 documentados.
- Backup actual creado y contraseña de restore guardada de forma segura.
- Secure Storage Master Key conocido y documentado.
- Port mapping preparado para WAN, LAN, DMZ, VLAN trunks y HA.
- Transferencia de licencia, registro en Central y estado de soporte comprobados.
- VPNs, NAT, WAF, SD-WAN, DHCP, DNS y routing preparados como lista de pruebas.
- RED, Access Points, ZTNA, Central 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.
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 Central 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 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.