Migrar Legacy Remote Access IPsec antes de SFOS 22 MR1
Con SFOS 22.0 MR1, Sophos eliminó definitivamente el Legacy Remote Access IPsec VPN de la ruta de upgrade soportada. Las firewalls en las que todavía exista esta configuración antigua de Remote Access IPsec no pueden actualizarse a SFOS 22.0 MR1 ni a versiones posteriores.
Este artículo describe 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 revisión general del upgrade también encaja revisar Sophos Firewall antes del upgrade a SFOS 22.
De qué trata Legacy Remote Access IPsec
Sophos ha soportado varias formas de Remote Access a lo largo de los años. Por eso, en muchos entornos no queda claro de inmediato si se habla de una configuración IPsec actual, de una entrada legacy antigua, de SSL VPN o de Sophos Connect.
Para el upgrade a SFOS 22 MR1, lo decisivo es sobre todo:
- Legacy Remote Access IPsec es el tipo de configuración antiguo que puede bloquear el upgrade.
- Remote Access IPsec actual es la ruta de destino si se quiere seguir usando IPsec.
- SSL VPN puede ser una alternativa si IPsec se bloquea con frecuencia en hoteles, redes de invitados o entornos móviles.
- ZTNA puede tener sentido cuando ya no se necesita una VPN de cliente completa, sino acceso a aplicaciones concretas.
La diferencia es importante en operación. Un estado VPN en verde o un Sophos Connect Client funcional no demuestra automáticamente que ya no exista ninguna configuración legacy en la firewall.
Un caso importante tras restore se pasa por alto con facilidad: los backups o las configuraciones importadas pueden contener Legacy Remote Access IPsec, pero esta configuración legacy no se migra automáticamente. Después de un restore, un cambio de hardware o una importación de configuración, conviene revisar este punto de nuevo, aunque antes la firewall ya pareciera limpia.
Cuándo conviene migrar
La migración debería estar terminada antes del upgrade planificado a SFOS 22 MR1. Este cambio no debería hacerse por primera vez durante la ventana de mantenimiento del firmware update, porque Remote Access suele afectar a usuarios, certificados, MFA, DNS, reglas de firewall y configuraciones de cliente.
Desencadenantes típicos:
- Sophos Firewall debe actualizarse a SFOS 22.0 MR1 o posterior.
- La página de firmware o la documentación de Sophos indican 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 tras cambios de perfil o de cliente.
- De todos modos se quiere reevaluar Remote Access con MFA, Entra ID SSO, SSL VPN o ZTNA.
Si Remote Access es crítico para el negocio, la migración debería tratarse como un proyecto de cambio propio. Un firmware upgrade es entonces 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 solo 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.
Revisar la configuración legacy en WebAdmin
Antes de planificar el destino, hay que determinar con claridad si realmente está afectado Legacy Remote Access IPsec. Esta revisión no corresponde solo 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), si el punto de menú aparece en la versión SFOS instalada.
- Comprobar si Legacy Remote Access IPsec está activado o si todavía existen objetos de configuración.
- Abrir Remote access VPN > IPsec y documentar por separado la configuración actual de Remote Access IPsec.
- Revisar Authentication > Users y los grupos de usuarios si se han usado direcciones IP estáticas, usuarios locales o asignaciones de grupos antiguas.
- Buscar en Rules and policies > Firewall rules reglas desde la zona
VPNhaciaLAN,DMZoWAN. - Revisar Administration > Device access para comprobar si IPsec, VPN Portal, DNS o Ping son accesibles desde las zonas necesarias.
- Volver a abrir la página de firmware y controlar si se sigue mostrando un bloqueador de upgrade.
Si el área legacy ya no es visible, pero el upgrade sigue bloqueado, no se deberían 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 limpiar con prisa durante la ventana de mantenimiento.
Como mínimo hay que documentar:
| Área | Qué conviene revisar |
|---|---|
| Usuarios y grupos | Qué usuarios pueden usar Remote Access? Se usan 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? Hay 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 perfiles actuales de Sophos Connect o las configuraciones SSL VPN? |
| Operación | Quién puede informar a los usuarios, distribuir perfiles y recibir errores? |
Si ya existen problemas con el routing o el tráfico a través del túnel, no deberían trasladarse sin revisar a la nueva configuración. Para el análisis ayuda Sophos Firewall IPsec VPN Troubleshooting.
Elegir la ruta de destino
No existe un único sustituto correcto para Legacy Remote Access IPsec. La elección depende de lo que los usuarios realmente necesitan y de cómo se opera el entorno.
Remote Access IPsec actual
Remote Access IPsec actual es la opción natural si se quiere seguir usando Sophos Connect con IPsec y el entorno funciona bien en principio con este enfoque. IPsec suele ser eficiente, pero puede llamar la atención en redes externas restrictivas por puertos UDP bloqueados o casos especiales de NAT.
Esta ruta encaja bien si:
- Sophos Connect ya está distribuido
- los usuarios trabajan principalmente con Windows o macOS
- IPsec ha sido estable en el uso anterior
- las redes internas deben ser accesibles mediante reglas de firewall clásicas
La guía existente configurar Sophos Connect Client en Sophos Firewall puede servir como base, pero debe compararse con las versiones SFOS actuales y con el propio diseño de autenticación.
SSL VPN
SSL VPN tiene sentido cuando Remote Access debe funcionar de la forma más robusta posible a través de distintas redes externas. Según el entorno, SSL VPN puede ser más sencillo, pero plantea otras preguntas de rendimiento y de cliente. Para Windows existe la guía instalar Sophos Connect SSL VPN Client.
Esta ruta encaja bien si:
- los usuarios trabajan a menudo en hoteles, WLAN de invitados o redes corporativas externas
- las conexiones IPsec fallan repetidamente por restricciones de red
- ya existen procesos SSL VPN establecidos
- las plataformas móviles o clientes OpenVPN de terceros tienen relevancia
ZTNA o Clientless Access
Si los usuarios solo necesitan aplicaciones web internas concretas o aplicaciones definidas, conviene revisar 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 ser la arquitectura mejor en casos de uso bien delimitados.
El artículo existente Sophos ZTNA Gateway Connector es un buen punto de entrada para ello. Para accesos web simples, Clientless Access también puede ser relevante si los requisitos encajan.
Crear la nueva configuración de Remote Access
La nueva configuración debería prepararse en paralelo antes de eliminar la antigua. El objetivo no es mover a todos los usuarios a la vez a una configuración sin probar.
Procedimiento recomendado:
- Definir la variante de destino: Remote Access IPsec actual, SSL VPN, ZTNA o combinación.
- Elegir un nuevo pool de IP y comprobar solapamientos.
- Definir fuente de autenticación y MFA.
- Asignar los usuarios o grupos necesarios.
- Definir servidores DNS y dominios internos.
- Crear reglas de firewall para las nuevas fuentes VPN.
- Generar un perfil de prueba para pocos usuarios.
- Probar la conexión en al menos dos accesos de red distintos.
- Solo después planificar la comunicación a usuarios y el rollout.
MFA no debería tratarse como un detalle opcional en Remote Access. Si la VPN es accesible mundialmente, MFA, grupos de usuarios limpios, logging y una revisión de los ajustes de Device Access van juntos. El artículo configurar MFA en Sophos Firewall cubre los fundamentos.
Planificar coexistencia y vía de retorno
La nueva solución de Remote Access debería probarse primero junto a la configuración antigua. Así se puede migrar a los usuarios por etapas y volver atrás de forma dirigida en caso de error, sin cambiar Remote Access, reglas de firewall, DNS, MFA y distribución de clientes al mismo tiempo en la misma ventana de mantenimiento.
Pero es importante planificar bien la coexistencia. La nueva configuración no debería usar 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 tarde en Log Viewer ya no se reconocerá qué acceso ha conectado realmente a un usuario.
Antes del piloto deberían estar claros estos puntos:
| Punto | Recomendación |
|---|---|
| Grupo piloto | pocos usuarios técnicamente accesibles con distintos dispositivos y redes |
| Pool de IP | rango propio sin solapamiento con LAN, WLAN, Site-to-Site VPN o Remote Access antiguo |
| Reglas de firewall | reglas propias y claramente nombradas para el nuevo pool VPN |
| Perfiles de cliente | nuevo nombre de perfil para que los usuarios distingan la conexión antigua de la nueva |
| Criterio de retorno | definir antes cuándo se vuelve a la conexión antigua |
| Ventana de soporte | Helpdesk o administración debe estar disponible durante el piloto |
Una vía de retorno no significa seguir operando la configuración legacy de forma permanente. Solo sirve para cancelar el piloto de forma controlada si el inicio de sesión, MFA, DNS, routing o aplicaciones centrales no funcionan. Cuando la nueva solución sea estable, conviene eliminar la configuración antigua y revisar de nuevo el bloqueador de upgrade.
Pruebas antes de eliminar la configuración legacy
La configuración antigua solo debería eliminarse cuando el reemplazo ya se haya probado. De lo contrario, el problema del upgrade queda resuelto, pero Remote Access puede fallar en producción.
Prueba funcional
Comprobar al menos:
- el inicio de sesión con usuario de prueba funciona
- MFA o SSO se solicita como se espera
- 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
- cierre de sesión y nuevo inicio de sesión funcionan
Prueba de firewall y routing
En Log Viewer, revisar si el tráfico de la zona VPN alcanza las reglas esperadas. Si el tráfico se descarta, no conviene revisar solo la configuración VPN, sino también la regla de firewall, NAT, Route Precedence y la ruta de retorno. Para conexiones individuales ayuda 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 deberían sobrescribirse sin avisar. Es mejor un piloto pequeño con feedback claro:
- 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?
- Los sufijos DNS, rutas y conexiones guardadas son correctos?
- Hay diferencias entre Windows y macOS?
Antes de un rollout amplio también conviene revisar la versión de cliente utilizada. Para ello encaja comprobar la versión de Sophos Connect Client y actualizar con seguridad.
Eliminar la configuración legacy
Cuando la nueva solución se haya probado en producción, se puede eliminar la configuración legacy. Antes debería crearse otra vez un backup actual. Esto es especialmente importante si en el mismo cambio también se adaptan 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.
- Dejar activa la nueva configuración de Remote Access.
- Eliminar Legacy Remote Access IPsec en WebAdmin.
- Revisar perfiles antiguos, pools de IP y reglas que ya no se necesiten.
- Volver a abrir la página de firmware y comprobar si ha desaparecido el bloqueador de upgrade.
- Documentar el resultado.
No hay que borrar inmediatamente todo lo que parezca antiguo. Las reglas de firewall, hosts o grupos antiguos también pueden usarse para Site-to-Site VPN, SSL VPN u otros fines. Primero revisar dependencias y después limpiar.
Después de un restore o una importación de configuración, la revisión debería repetirse. Un backup puede contener objetos legacy antiguos sin que de ahí surja automáticamente una configuración actual de Remote Access IPsec. Para operación y documentación, por tanto, lo decisivo es si la configuración productiva de destino realmente se creó, probó y distribuyó de nuevo.
Troubleshooting
El upgrade sigue bloqueado
Si el upgrade sigue bloqueado aunque la configuración legacy visible se haya eliminado, primero recargar la firewall o volver a abrir el área de firmware. Después comprobar si realmente se han eliminado todos los objetos de Legacy Remote Access. Si sigue sin quedar claro qué objeto bloquea, conviene preparar un Sophos Support Case con captura de pantalla del mensaje de upgrade y 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, conviene revisar Remote Access de nuevo. Lo decisivo no es si el cambio anterior se había completado una vez, sino qué existe en la configuración actualmente activa. Los backups antiguos pueden traer de vuelta objetos históricos de Remote Access o activar una nueva revisión de la ruta de upgrade.
Los usuarios no pueden iniciar sesión
Ante problemas de inicio de sesión, revisar primero autenticación, MFA, grupo de usuarios y VPN policy. Si participan RADIUS, AD o Entra ID, conviene probar la conexión al servidor por separado de la VPN. Un problema VPN no siempre es un problema IPsec.
La conexión está activa, pero los sistemas internos no son accesibles
Entonces la causa suele estar en reglas de firewall, NAT, DNS o routing. Revisar si el cliente recibe una IP VPN adecuada, si los nombres internos se resuelven correctamente y si el tráfico en Log Viewer alcanza la regla esperada.
Algunas redes funcionan y otras no
En este caso suelen intervenir redes Split Tunnel, rutas IPsec, rutas estáticas o rutas de retorno faltantes. En 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
- ruta de destino elegida: IPsec actual, SSL VPN, ZTNA o combinación
- MFA y autenticación revisados
- Device Access para IPsec, VPN Portal, DNS y Ping revisado
- coexistencia y criterio de retorno definidos
- usuario de prueba definido
- backup creado
Durante el rollout
- nueva configuración probada con usuarios piloto
- perfiles de cliente distribuidos
- Log Viewer y reglas de firewall afectadas revisados
- vía de retorno comunicada
- feedback de usuarios recogido
Después de la migración
- configuración legacy eliminada
- bloqueador de upgrade revisado de nuevo
- escenario de restore e importación documentado
- perfiles y reglas antiguos revisados por dependencias
- documentación actualizada
- firmware upgrade planificado solo después