Migrar Legacy Remote Access IPsec antes de SFOS 22 MR1

Con SFOS 22.0 MR1, Sophos ha retirado Legacy Remote Access IPsec VPN. Basta con que exista una configuración legacy en el firewall para bloquear el upgrade a SFOS 22.0 MR1 y versiones posteriores. Debe eliminarse antes del upgrade, aunque nadie la utilice actualmente para conectarse.

Este artículo explica cómo detectar la configuración antigua antes de un firmware upgrade, documentarla correctamente, sustituirla por una solución actual de Remote Access y eliminarla solo después. Para la comprobación general del upgrade también resulta útil comprobar Sophos Firewall antes del upgrade a SFOS 22.

Qué es Legacy Remote Access IPsec

Sophos ha admitido varias opciones de Remote Access a lo largo de los años. Por eso, en muchos entornos no queda claro de inmediato si se trata de una configuración IPsec actual, una entrada legacy antigua, SSL VPN o Sophos Connect.

Para el upgrade a SFOS 22 MR1, lo más importante es lo siguiente:

Legacy Remote Access IPsec es el tipo de configuración antiguo que puede bloquear el upgrade.
Remote Access IPsec actual es la opción de destino si se quiere seguir utilizando IPsec.
SSL VPN puede ser una alternativa si IPsec se bloquea con frecuencia en hoteles, redes de invitados o redes móviles.
ZTNA puede ser adecuado cuando ya no se necesita una VPN de cliente completa, sino acceso a aplicaciones concretas.

La diferencia es importante desde el punto de vista operativo. Un estado VPN en verde o un Sophos Connect Client funcional no demuestran automáticamente que ya no exista una configuración legacy en el firewall.

Los archivos de cliente también ayudan a identificarla:

En una conexión legacy, de un archivo .tar descargado se extraía un archivo .tgb y se importaba en un cliente VPN de terceros.
La configuración actual de Remote Access IPsec puede exportar un archivo .scx para Sophos Connect. Este contiene tanto los ajustes generales como los avanzados.
Un archivo .tgb actual no demuestra por sí solo que exista una configuración legacy, ya que la página IPsec actual sigue permitiendo exportarlo para clientes de terceros. Lo determinante es la entrada en Remote access VPN > IPsec (legacy).

Hay un caso importante relacionado con los restores que se pasa por alto con facilidad: los backups o las configuraciones importadas pueden contener Legacy Remote Access IPsec. Sophos restaura o importa esta configuración, pero no la migra al modelo actual de Remote Access IPsec. Por eso, después de un restore, un cambio de hardware o una importación de configuración, es necesario volver a comprobar el bloqueo del upgrade.

Cuándo se debe migrar

La migración debe estar terminada antes del upgrade previsto a SFOS 22 MR1. Este cambio no debe realizarse por primera vez durante la ventana de mantenimiento del firmware update, ya que Remote Access suele afectar a usuarios, certificados, MFA, DNS, reglas de firewall y configuraciones de cliente.

Motivos habituales:

Sophos Firewall debe actualizarse a SFOS 22.0 MR1 o una versión posterior.
La página de firmware o la documentación de Sophos advierten sobre Legacy Remote Access IPsec.
En el entorno existen perfiles antiguos de Sophos Connect que no se han revisado desde hace años.
Los usuarios notifican problemas recurrentes de Remote Access después de cambiar de perfil o cliente.
Se quiere reevaluar Remote Access con MFA, Entra ID SSO, SSL VPN o ZTNA.

Si Remote Access es crítico para la empresa, la migración debe tratarse como un proyecto de cambio independiente. En ese caso, el firmware upgrade es solo el motivo, no todo el alcance del trabajo.

Documentar antes de la migración

Primero se documenta el estado actual. Este paso es más importante de lo que parece, porque muchas configuraciones VPN no constan únicamente de un perfil de túnel. A menudo dependen de grupos de usuarios, pools de IP, ajustes DNS, reglas de firewall, excepciones NAT y archivos de cliente.

Comprobar la configuración legacy en WebAdmin

Antes de planificar la solución de destino, hay que determinar con claridad si realmente está afectado Legacy Remote Access IPsec. Esta comprobación no solo debe hacerse antes del firmware upgrade, sino también después de un restore, un cambio de hardware o una importación de configuración.

Procedimiento práctico:

Abrir Remote access VPN > IPsec (legacy) en la versión de origen todavía compatible.
Comprobar si existe una conexión legacy. Para el bloqueo del upgrade, no importa si se utiliza activamente en ese momento.
Abrir Remote access VPN > IPsec y documentar por separado la configuración actual de Remote Access IPsec.
Comprobar Authentication > Users y los grupos de usuarios si se han utilizado direcciones IP estáticas, usuarios locales o asignaciones de grupos antiguas.
Buscar en Rules and policies > Firewall rules reglas desde la zona VPN hacia LAN, DMZ o WAN.
Comprobar en Administration > Device access si IPsec, VPN Portal, DNS o Ping son accesibles desde las zonas necesarias.
Volver a abrir la página de firmware y comprobar si sigue apareciendo un bloqueo del upgrade.

Si la sección legacy ya no está visible, pero el upgrade continúa bloqueado, no se deben eliminar objetos por sospecha. En ese caso, una captura de pantalla del mensaje, un backup actual y una lista de objetos comprensible son más importantes que una limpieza apresurada durante la ventana de mantenimiento.

Como mínimo, se debe documentar lo siguiente:

Usuarios y grupos: ¿Qué usuarios pueden utilizar Remote Access? ¿Se utilizan usuarios locales, AD, RADIUS o Entra ID?
Autenticación: Contraseña, MFA, certificado, Preshared Key o dependencias de SSO.
Pool de IP: ¿Qué direcciones reciben los clientes VPN? ¿Existen conflictos con LAN, WLAN, VLAN u otras VPN?
DNS: ¿Qué servidores DNS y dominios se distribuyen a los clientes?
Acceso: ¿Qué redes internas, servidores y servicios deben ser accesibles?
Reglas de firewall: ¿Qué reglas permiten tráfico de VPN hacia LAN, DMZ o WAN?
Distribución de clientes: ¿Dónde están los archivos .tgb antiguos, los perfiles actuales de Sophos Connect (.scx o .pro) o las configuraciones SSL VPN?
Operación: ¿Quién puede informar a los usuarios, distribuir perfiles y recibir notificaciones de errores?

Si ya existen problemas de routing o tráfico a través del túnel, no deben trasladarse sin revisar a la nueva configuración. Para el análisis resulta útil Sophos Firewall IPsec VPN Troubleshooting.

Elegir la solución de destino

No existe un único sustituto correcto para Legacy Remote Access IPsec. La elección depende de lo que los usuarios necesiten realmente y de cómo se gestione el entorno.

Remote Access IPsec actual

Remote Access IPsec actual es la opción más lógica si se quiere seguir utilizando Sophos Connect con IPsec y el entorno funciona bien con este enfoque. IPsec suele ofrecer un buen rendimiento, pero puede dar problemas en redes externas restrictivas por puertos UDP bloqueados o casos especiales de NAT.

Esta opción encaja bien si:

Sophos Connect ya está distribuido
los usuarios trabajan con Windows 10/11 o macOS 13 y versiones posteriores
IPsec ha sido estable hasta ahora
las redes internas deben ser accesibles mediante reglas de firewall convencionales

Sophos Connect admite Remote Access IPsec actual en estas versiones de Windows y macOS. Para Linux y otras plataformas móviles se necesita un cliente de terceros adecuado; iOS puede instalar su propio perfil IPsec desde VPN Portal. La guía existente configurar Sophos Connect Client en Sophos Firewall describe la configuración completa.

SSL VPN

SSL VPN resulta adecuado cuando Remote Access debe funcionar de la forma más fiable posible a través de distintas redes externas. Según el entorno, SSL VPN puede ser más sencillo, pero plantea otras cuestiones de rendimiento y cliente. Para Windows está disponible la guía instalar Sophos Connect SSL VPN Client.

Esta opción encaja bien si:

los usuarios trabajan con frecuencia en hoteles, redes Wi-Fi de invitados o redes de otras empresas
las conexiones IPsec fallan repetidamente por restricciones de red
ya existen procesos establecidos para SSL VPN
las plataformas móviles o los clientes OpenVPN de terceros son relevantes

ZTNA o Clientless Access

Si los usuarios solo necesitan aplicaciones web internas concretas o aplicaciones definidas, conviene comprobar si una VPN clásica de túnel completo sigue siendo la solución adecuada. ZTNA no sustituye directamente todos los escenarios VPN, pero puede ofrecer una arquitectura mejor en casos de uso claramente delimitados.

Para tomar esta decisión, conviene empezar por ¿Qué es Zero Trust Network Access? Fundamentos, ventajas y límites. Si se va a utilizar Sophos ZTNA, Sophos ZTNA Gateway Connector describe el componente específico. Clientless Access solo es una alternativa para servicios adecuados basados en navegador y no sustituye el acceso general a la red.

Crear la nueva configuración de Remote Access

La nueva configuración debe prepararse en paralelo antes de eliminar la antigua. El objetivo no es trasladar a todos los usuarios al mismo tiempo a una configuración que no se ha probado.

Para Remote Access IPsec actual no basta con crear un nuevo nombre de perfil. El proceso de migración debe adoptar o volver a definir de forma consciente los ajustes clave:

Definir la variante de destino: Remote Access IPsec actual, SSL VPN, ZTNA o una combinación.
En Remote access VPN > IPsec, activar Remote Access y seleccionar la Interface externa.
Utilizar un IPsec profile adecuado. Remote Access acepta perfiles IKEv1 en los que Dead Peer Detection está desactivado o configurado como Disconnect.
Definir Authentication type, la ID local y remota, y Allowed users and groups.
En Assign IP from, elegir un rango privado de al menos una subred /24. No debe solaparse con SSL VPN, L2TP, PPTP, LAN, WLAN ni redes Site-to-Site.
Definir DNS server 1 y, opcionalmente, DNS server 2, además de los recursos internos necesarios.
Decidir de forma consciente entre Split Tunnel o Use as default gateway y configurar Prompt users for 2FA token de acuerdo con el método MFA.
En Authentication > Groups, comprobar si Remote Access IPsec está permitido para el grupo de usuarios que se aplica realmente. Esto no se activa automáticamente en grupos AD importados ni en grupos migrados.
En Administration > Device access, permitir IPsec desde la zona WAN. VPN Portal solo es necesario si los clientes o el aprovisionamiento acceden a través de él; DNS y Ping solo se habilitan si el diseño concreto lo requiere.
Crear reglas de firewall independientes y con nombres claros para el tráfico VPN entrante y saliente, y activar el logging.
Utilizar Export connection para generar un archivo .scx para Sophos Connect o actualizar un aprovisionamiento .pro existente.
Distribuir el perfil de prueba a unos pocos usuarios piloto, probarlo en al menos dos conexiones de red diferentes y planificar el rollout solo después.

MFA no debe tratarse como un detalle opcional en Remote Access. Si la VPN es accesible desde cualquier parte del mundo, MFA, grupos de usuarios bien definidos, logging y una revisión de los ajustes de Device Access deben abordarse conjuntamente. El artículo configurar MFA en Sophos Firewall cubre los fundamentos.

Planificar la coexistencia y la vía de retorno

La nueva solución de Remote Access debe probarse primero junto a la configuración antigua. Así se puede migrar a los usuarios por etapas y volver atrás de forma controlada en caso de error, sin cambiar al mismo tiempo Remote Access, reglas de firewall, DNS, MFA y distribución de clientes durante la misma ventana de mantenimiento.

Sin embargo, es importante planificar correctamente la coexistencia. La nueva configuración no debe utilizar el mismo pool de IP, las mismas reglas de firewall con nombres poco claros ni los mismos nombres de perfil que la configuración legacy antigua. De lo contrario, más adelante no se podrá identificar en Log Viewer qué acceso conectó realmente a un usuario.

Antes del piloto deben quedar claros estos puntos:

Grupo piloto: Unos pocos usuarios accesibles para el equipo técnico, con distintos dispositivos y redes.
Pool de IP: Un rango propio sin solapamiento con LAN, WLAN, Site-to-Site VPN o el Remote Access antiguo.
Reglas de firewall: Reglas propias y con nombres claros para el nuevo pool VPN.
Perfiles de cliente: Un nuevo nombre de conexión para que los usuarios puedan distinguir la conexión legacy de la conexión de destino.
Criterio de retorno: Definir previamente cuándo se volverá a la conexión antigua.
Ventana de soporte: Helpdesk o el equipo de administración deben estar disponibles durante el piloto.

Una vía de retorno no significa mantener permanentemente la configuración legacy. Solo sirve para cancelar el piloto de forma controlada si el inicio de sesión, MFA, DNS, routing o las aplicaciones centrales no funcionan. Cuando la nueva solución sea estable, se debe eliminar la configuración antigua y volver a comprobar el bloqueo del upgrade.

Pruebas antes de eliminar la configuración legacy

La configuración antigua solo debe eliminarse una vez que se haya probado la solución alternativa. De lo contrario, se habrá resuelto el problema del upgrade, pero Remote Access podría fallar en producción.

Prueba funcional

Comprobar como mínimo que:

funciona el inicio de sesión con un usuario de prueba
MFA o SSO se solicitan según lo previsto
el cliente recibe una IP VPN adecuada
los nombres DNS internos se resuelven
los servidores centrales son accesibles
el comportamiento de Internet corresponde al diseño: Split Tunnel o Full Tunnel
funcionan el cierre de sesión y el nuevo inicio de sesión

Prueba de firewall y routing

En Log Viewer, comprobar si el tráfico de la zona VPN alcanza las reglas esperadas. Si se descarta tráfico, no solo debe revisarse la configuración VPN, sino también la regla de firewall, NAT, Route Precedence y la ruta de retorno. Para conexiones individuales resulta útil el artículo probar una regla de firewall con Log Viewer, Policy Test y Packet Capture.

Prueba de cliente

Con Sophos Connect, los perfiles existentes no deben sobrescribirse sin informar al usuario. Es preferible realizar un piloto pequeño con comentarios claros:

¿El cliente importa la nueva configuración?
¿La conexión antigua se sustituye de forma comprensible para los usuarios?
¿La conexión se establece después de un reinicio?
¿Son correctos los sufijos DNS, las rutas y las conexiones guardadas?
¿Hay diferencias entre Windows y macOS?

Al distribuir archivos .scx, cualquier cambio posterior debe volver a exportarse e importarse. Un aprovisionamiento .pro ya configurado puede obtener los cambios posteriores automáticamente, siempre que la dirección del gateway y el puerto de VPN Portal sean accesibles y no cambien.

Antes de un rollout amplio también debe comprobarse la versión de cliente utilizada. Para ello resulta útil comprobar la versión de Sophos Connect Client y actualizarla de forma segura.

Eliminar la configuración legacy

Una vez que la nueva solución se haya probado en producción, se puede eliminar la configuración legacy. Antes debe crearse de nuevo un backup actual. Esto es especialmente importante si en el mismo cambio también se modifican reglas de firewall, grupos de usuarios o servidores de autenticación.

Procedimiento práctico:

Crear un backup reciente.
Informar a los usuarios activos sobre la ventana de mantenimiento.
Mantener activa la nueva configuración de Remote Access.
Eliminar Legacy Remote Access IPsec en WebAdmin.
Comprobar las dependencias de los perfiles, pools de IP y reglas antiguos que ya no sean necesarios.
Volver a abrir la página de firmware y comprobar si ha desaparecido el bloqueo del upgrade.
Documentar el resultado.

No se debe eliminar de inmediato todo lo que parezca antiguo. Las reglas de firewall, los hosts o los grupos antiguos también pueden utilizarse para Site-to-Site VPN, SSL VPN u otros fines. Primero hay que comprobar las dependencias y después limpiar.

Después de un restore o una importación de configuración, debe repetirse la comprobación. Un backup puede contener objetos legacy antiguos sin que de ellos surja automáticamente una configuración actual de Remote Access IPsec. Por eso, para la operación y la documentación es decisivo que la configuración productiva de destino se haya creado, probado y distribuido realmente de nuevo.

Troubleshooting

El upgrade sigue bloqueado

Si el upgrade sigue bloqueado a pesar de haber eliminado la configuración legacy visible, primero hay que volver a abrir la sección de firmware y comprobar de nuevo Remote access VPN > IPsec (legacy). No se deben eliminar por sospecha hosts, grupos ni perfiles IPsec actuales. Si sigue sin estar claro qué configuración legacy se detecta, debe prepararse un Sophos Support Case con una captura de pantalla del mensaje de upgrade, la versión de origen y un backup actual.

La cuestión legacy reaparece después de un restore

Después de un restore, un cambio de hardware o la importación de una configuración antigua, se debe volver a comprobar Remote Access. Lo decisivo no es si el cambio anterior se completó una vez, sino qué contiene la configuración que se está ejecutando actualmente. Los backups antiguos pueden recuperar objetos históricos de Remote Access o hacer necesaria una nueva comprobación de la ruta de upgrade.

Los usuarios no pueden iniciar sesión

Ante problemas de inicio de sesión, primero hay que comprobar la autenticación, MFA, el grupo de usuarios y la VPN policy. Si intervienen RADIUS, AD o Entra ID, la conexión al servidor debe probarse por separado de la VPN. Un problema de VPN no siempre es un problema de IPsec.

La conexión está activa, pero los sistemas internos no son accesibles

En ese caso, la causa suele estar en las reglas de firewall, NAT, DNS o routing. Hay que comprobar si el cliente recibe una IP VPN adecuada, si los nombres internos se resuelven correctamente y si el tráfico alcanza la regla esperada en Log Viewer.

Algunas redes funcionan y otras no

En este caso, suelen intervenir las redes Split Tunnel, las rutas IPsec, las rutas estáticas o la falta de rutas de retorno. Para escenarios IPsec, ruta IPsec en Sophos Firewall es un artículo complementario útil.

Checklist

Antes del rollout

Legacy Remote Access IPsec identificado
usuarios, grupos, pool de IP, DNS y reglas de firewall documentados
solución de destino elegida: IPsec actual, SSL VPN, ZTNA o una combinación
MFA y autenticación comprobados
Device Access comprobado según las necesidades: IPsec en WAN, VPN Portal para distribución o aprovisionamiento, DNS y Ping solo si son necesarios
coexistencia y criterio de retorno definidos
usuarios de prueba definidos
backup creado

Durante el rollout

nueva configuración probada con usuarios piloto
perfiles de cliente distribuidos
Log Viewer y reglas de firewall afectadas comprobados
vía de retorno comunicada
comentarios de los usuarios recopilados

Después de la migración

configuración legacy eliminada
bloqueo del upgrade comprobado de nuevo
escenario de restore e importación documentado
perfiles y reglas antiguos comprobados para detectar dependencias
documentación actualizada
firmware upgrade planificado solo después

FAQ

¿Debe eliminarse Legacy Remote Access IPsec antes de SFOS 22 MR1?

Sí. Si esta configuración legacy todavía existe, el firewall no puede actualizarse a SFOS 22.0 MR1 ni a una versión posterior.

¿También está afectado Remote Access IPsec actual?

No. El bloqueo del upgrade se refiere a Legacy Remote Access IPsec. Aun así, la configuración actual de Remote Access debe probarse y documentarse antes de un Major Upgrade.

¿Es SSL VPN la mejor alternativa?

No en todos los casos. SSL VPN suele tolerar mejor las redes externas restrictivas. En cambio, IPsec puede ofrecer un mayor rendimiento. Los factores decisivos son los dispositivos de los usuarios, los entornos de red, la autenticación, MFA y los procesos operativos.

¿Se puede eliminar sin más la configuración antigua?

Técnicamente se puede eliminar, pero en la práctica primero debe probarse una solución alternativa y crearse un backup. De lo contrario, Remote Access puede dejar de funcionar para los usuarios.

¿Qué ocurre después de un restore con una configuración legacy antigua?

Después de un restore o una importación de configuración, se debe volver a comprobar Legacy Remote Access IPsec. Sophos puede restaurar o importar la configuración antigua, pero no la migra a la configuración actual de Remote Access IPsec. Por tanto, puede seguir bloqueando el upgrade.