Sophos Firewall: corregir el corte de IPsec tras 4 horas

Si Sophos Connect con IPsec Remote Access y OTP se desconecta al cabo de unas cuatro horas, la causa puede ser el rekeying de IKEv1 documentado para el perfil predeterminado. Durante el rekeying de la fase 1, el firewall vuelve a solicitar un OTP y el túnel existente se interrumpe. Sophos indica un intervalo aproximado de cuatro horas para el perfil predeterminado.

Este artículo explica cómo clasificar este comportamiento, qué registros encajan con él y cómo adaptar correctamente el valor mediante un perfil IPsec propio. Para la configuración básica de Sophos Connect, consulte primero Configurar Sophos Connect en Sophos Firewall. Para decidir entre IPsec, SSL VPN, clientes móviles y ZTNA, es mejor empezar por Sophos Connect o SSL VPN: ¿qué solución de acceso remoto es la adecuada?.

⚠️ Importante: Esta causa afecta a IPsec Remote Access con IKEv1 y OTP. Aumentar la duración de IKE no corrige una desconexión de SSL VPN, un Idle Timeout configurado ni una conexión a Internet inestable.

Delimitar primero la causa

El problema de rekeying es probable si coinciden varios indicios:

• Sophos Connect se desconecta periódicamente al cabo de unas cuatro horas.
• Tras la desconexión, los usuarios deben volver a confirmar el OTP o MFA.
• La conexión era estable y vuelve a funcionar después de iniciar sesión de nuevo.
• Otros perfiles VPN o conexiones SSL VPN no presentan este comportamiento.
• Los momentos de desconexión coinciden con el rekeying de la fase 1 del perfil IPsec asignado.
• En el registro VPN aparecen mensajes de IKE, autenticación o rekeying que coinciden con la desconexión.

Compruebe primero en Remote access VPN > IPsec qué IPsec profile está seleccionado y si se ha activado Disconnect when tunnel is idle. Un Idle Timeout solo finaliza las conexiones inactivas una vez transcurrido el Idle session time interval configurado. Es un comportamiento distinto de una desconexión recurrente por OTP durante el uso activo.

Si la conexión se interrumpe de forma aleatoria, solo falla en determinadas redes o no transporta tráfico justo después de establecerse, se requiere un diagnóstico general de IPsec VPN.

Descartar primero Legacy Remote Access IPsec

Especialmente en entornos antiguos, primero debe aclararse qué variante de IPsec Remote Access se utiliza. Este artículo trata la configuración actual de IPsec Remote Access con Sophos Connect y perfiles IPsec. No es el punto de partida adecuado si todavía existe Legacy Remote Access IPsec o si está bloqueada una actualización a SFOS 22.0 MR1.

Clasificación práctica:

• La conexión se interrumpe tras un tiempo similar y después vuelve a establecerse: Este artículo es el siguiente paso adecuado.
• La actualización a SFOS 22.0 MR1 o posterior está bloqueada debido a Legacy IPsec: Primero, migrar Legacy Remote Access IPsec antes de SFOS 22 MR1.
• El túnel está conectado, pero los destinos internos no son accesibles: Continúe con Diagnóstico de IPsec VPN en Sophos Firewall.
• Los usuarios deben cambiar de IPsec a SSL VPN, ZTNA u otro modelo: Consulte Sophos Connect o SSL VPN: ¿qué solución de acceso remoto es la adecuada?.

Esta distinción es importante porque ajustar la duración de las claves no sustituye a un plan de migración. Si todavía hay una configuración Legacy antigua en el firewall, debe documentarse, sustituirse y eliminarse correctamente antes de una actualización importante del firmware.

Por qué el rekeying de IKEv1 con OTP interrumpe el túnel

Sophos Connect utiliza un perfil IKEv1 para IPsec Remote Access. En muchos entornos está asignado DefaultRemoteAccess. Este perfil determina, entre otros aspectos, la duración de la Security Association de la fase 1 y el momento en que comienza la renegociación.

Tres campos son relevantes para determinar ese momento:

• Key life: duración máxima de la SA de fase 1 en segundos.
• Re-key margin: periodo anterior al vencimiento de Key life en el que comienza la renegociación.
• Randomize re-keying margin by: variación porcentual del momento del rekeying para evitar que todos los túneles renegocien simultáneamente.

La captura de pantalla existente muestra una Key life de 18000 segundos para DefaultRemoteAccess. Sin embargo, de este valor no puede deducirse una fórmula universal de cuatro horas: el Re-key margin, la aleatorización, el comportamiento del cliente y la autenticación influyen en el momento en que la interrupción se hace visible. Los valores determinantes son los del perfil realmente asignado y las marcas de tiempo del caso concreto.

La decisión técnica es importante: un valor mayor reduce las reautenticaciones, pero también prolonga la duración de la IKE-SA. Es una decisión operativa y de seguridad, no un simple ajuste de comodidad.

Correlacionar los registros con la duración de la conexión

En Log viewer, abra el área VPN y compare el establecimiento de la conexión con la desconexión posterior del mismo usuario. Anote la hora de inicio, el usuario, la IP pública del cliente y el momento de la nueva solicitud de OTP. Registre además el estado del cliente Sophos Connect en ese mismo momento.

Los mensajes como invalid SPI pueden aparecer después de que las Security Associations hayan caducado o ya hayan sido sustituidas. Sin embargo, por sí solos no demuestran este problema. Es más concluyente la combinación de una duración periódica, un perfil IKEv1, una solicitud de OTP y un rekeying de fase 1 coincidente en el tiempo. Para problemas VPN recurrentes, también resultan útiles Guardar registros de Sophos Firewall para soporte y análisis y Diagnóstico de Sophos Firewall: servicios y registros.

Adaptar el perfil IPsec mediante la GUI

El método más adecuado es no trabajar directamente sobre el perfil predeterminado, sino clonarlo y utilizar conscientemente el nuevo valor para Remote Access.

La ruta de menú actual es:

Profiles > IPsec profiles

Procedimiento:

1. Haga clic en Clone junto a DefaultRemoteAccess.
2. Asigne un nombre inequívoco al nuevo perfil, por ejemplo, RemoteAccess_OTP_12h.
3. Mantenga Key exchange en IKEv1 y deje activado Re-key connection.
4. En Phase 1, compruebe los valores Key life, Re-key margin y Randomize re-keying margin by.
5. Introduzca el valor deseado de Key life. Sophos documenta un máximo de 24 horas para esta solución alternativa, es decir, 86400 segundos como máximo.
6. En Phase 2, compruebe que su Key life siga siendo inferior al valor de la fase 1.
7. En Dead peer detection, utilice una opción disponible para Remote Access: desactivado o When peer unreachable: Disconnect.
8. Guarde el perfil.
9. En Remote access VPN > IPsec, seleccione el nuevo IPsec profile y guarde la configuración.
10. Proporcione la configuración actualizada de Sophos Connect y pruébela primero con un usuario piloto.

Después del cambio, no basta con guardar el firewall. Si se distribuyen archivos .scx manualmente, debe exportarse un archivo actualizado mediante Export connection en Remote access VPN > IPsec y volver a importarse en los clientes. Si ya se utiliza un archivo de aprovisionamiento .pro con Sophos Connect 2.1 o posterior, el cliente obtiene automáticamente del VPN Portal los cambios de configuración posteriores. Para ello, la dirección de gateway y el puerto de VPN Portal no deben haberse modificado entretanto.

Para el funcionamiento y las versiones del cliente, consulte Comprobar y actualizar de forma segura la versión de Sophos Connect Client. Para instalaciones en Windows, consulte Instalar Sophos Connect Client en Windows, y para macOS, Instalar Sophos Connect Client en macOS.

Establecer una duración adecuada

No existe una fórmula fiable que permita calcular un único valor de ikekeylife a partir del intervalo deseado entre solicitudes de OTP. Key life es la duración máxima de la SA; el rekeying comienza dentro del Re-key margin y, además, puede aleatorizarse.

Por ejemplo, 43200 segundos equivalen a doce horas de Key life. La renegociación comienza antes en función del Re-key margin y de la aleatorización. Por ello, el valor no debe describirse como una sesión de usuario garantizada de doce horas. Sophos establece 24 horas como límite máximo para esta solución alternativa.

Antes del cambio deben aclararse los siguientes puntos:

• ¿Qué duración máxima de las claves IKE y qué intervalo de rekeying son aceptables desde el punto de vista de la seguridad?
• ¿El valor se ajusta a los horarios de trabajo, los turnos y el proceso de helpdesk?
• ¿Se utiliza OTP, RADIUS-MFA, Entra ID SSO u otro método de autenticación?
• ¿Existen requisitos de cumplimiento para la reautenticación?
• ¿Funcionan de forma fiable el rekeying o la reconexión con la versión actual de Sophos Connect Client?

Para los fundamentos de MFA en el firewall, consulte Activar MFA para Sophos Firewall WebAdmin, VPN Portal y Remote Access. Si se utiliza Microsoft Entra ID SSO, también debe tenerse en cuenta Configurar Microsoft Entra ID SSO para Sophos Connect y VPN Portal.

Por qué no se recomienda modificar directamente la base de datos

Algunos Runbooks antiguos incluyen modificaciones directas en Advanced Shell o comandos SQL contra la base de datos del firewall. No es una práctica recomendable para el funcionamiento normal.

Motivos:

• La intervención evita la validación normal de WebAdmin.
• Los valores incorrectos pueden afectar a los perfiles VPN o a Remote Access.
• Los cambios son más difíciles de rastrear.
• En los casos de soporte, un cambio limpio mediante la GUI es más fácil de explicar.
• El comportamiento interno puede cambiar después de las actualizaciones.

Por ello, el valor debe establecerse mediante un perfil IPsec propio en WebAdmin. Las modificaciones directas de la base de datos solo deben realizarse, como máximo, en un contexto claramente definido por el soporte de Sophos, y no como parte de una guía de administración normal.

Probar el cambio durante la ventana de rekeying

Después de la adaptación debe realizarse una prueba limitada con usuarios piloto.

Puntos de comprobación:

1. El nuevo perfil está seleccionado en IPsec Remote Access.
2. Se ha importado el nuevo archivo .scx o el aprovisionamiento mediante .pro ha obtenido el cambio.
3. La conexión se establece correctamente.
4. Los destinos internos son accesibles.
5. DNS, el routing y las reglas de firewall funcionan.
6. La conexión permanece activa hasta la ventana de rekeying esperada.
7. Durante el rekeying no se produce ninguna interrupción imprevista ni un bucle de OTP poco claro.
8. Los registros VPN muestran la renegociación esperada sin errores nuevos.

Si la conexión se establece pero no circula tráfico, es más probable que el problema esté en las rutas, las reglas de firewall, NAT o DNS. En ese caso, consulte Probar una regla de firewall con Log Viewer, Policy Test y Packet Capture.

Errores habituales

Problemas frecuentes:

• Se ha modificado directamente el perfil predeterminado: Otros escenarios de Remote Access pueden verse afectados involuntariamente. Es preferible utilizar un perfil clonado y asignarlo de forma específica.
• No se ha actualizado el perfil del cliente: Si los archivos .scx se distribuyen manualmente, los usuarios siguen utilizando los ajustes antiguos. En cambio, con un aprovisionamiento .pro que funcione, los cambios posteriores se obtienen automáticamente.
• Valor de Key life demasiado largo: Menos reautenticaciones implican una mayor duración de la IKE-SA. Los requisitos operativos y de seguridad deben evaluarse conjuntamente.
• Solo se ha reinstalado el cliente: El perfil del firewall permanece sin cambios. El perfil del firewall y la configuración del cliente deben comprobarse conjuntamente.
• Se ha utilizado invalid SPI como única prueba: El mensaje también puede ser consecuencia de SAs ya sustituidas. La duración de la conexión, el rekeying de IKE y la solicitud de OTP deben coincidir en el tiempo.
• Se ha modificado directamente la base de datos: Esto aumenta el riesgo de problemas de soporte y configuración. Para el funcionamiento normal debe utilizarse el perfil de la GUI.

Lista de comprobación operativa

• Registrar los usuarios afectados y los momentos en que se produce el problema.
• Comprobar si se utiliza IPsec Remote Access con Sophos Connect.
• Revisar los registros VPN en busca de indicios de IKE, SPI y rekeying.
• Identificar el perfil IPsec utilizado.
• Clonar DefaultRemoteAccess en lugar de modificarlo directamente.
• Registrar los valores de la fase 1 para Key life, Re-key margin y la aleatorización.
• Definir técnicamente un valor objetivo de hasta 24 horas como máximo.
• Asignar el nuevo perfil en IPsec Remote Access.
• Volver a distribuir la configuración del cliente.
• Realizar pruebas con usuarios piloto e informar al helpdesk.
• Comprobar después de unos días si se producen menos casos de reconexión por OTP.

FAQ