Résoudre le timeout IPsec Remote Access après 4 heures

Lorsque Sophos Connect avec IPsec Remote Access et OTP se déconnecte après environ quatre heures, le rekeying IKEv1 documenté du profil par défaut peut en être la cause. Lors du rekeying de la phase 1, le pare-feu demande un nouvel OTP et le tunnel existant est interrompu. Sophos indique un intervalle d’environ quatre heures pour le profil par défaut.

Cet article explique comment interpréter ce comportement, quels journaux permettent de le confirmer et comment adapter proprement la valeur au moyen d’un profil IPsec personnalisé. Pour la configuration de base de Sophos Connect, consultez d’abord Configurer Sophos Connect sur Sophos Firewall. Pour choisir entre IPsec, SSL VPN, clients mobiles et ZTNA, Sophos Connect ou SSL VPN : quelle solution d’accès distant choisir ? constitue un meilleur point de départ.

⚠️ Important : Cette cause concerne Remote Access IPsec avec IKEv1 et OTP. Une durée de vie IKE plus longue ne résout ni une déconnexion SSL VPN, ni un Idle Timeout configuré, ni une connexion Internet instable.

Contexte de version : Vérifiez SFOS 22.0 MR2 Build 546 et mettez à jour le firmware en toute sécurité. Pour SFOS 22, Sophos prend en charge Sophos Connect 2.5 MR1 et versions antérieures sous Windows, et 2.0 MR1 et versions antérieures sous macOS. Avant toute modification, relevez le build sous Backup & firmware > Firmware et la version du client sous About. Le guide de vérification et de mise à jour sécurisée de Sophos Connect couvre également NCL-2992, corrigé dans 2.5 MR1, qui provoquait des demandes OTP incohérentes lors d’une reconnexion VPN. Un ancien client doit donc être exclu comme cause distincte.

Commencer par identifier la cause

Le problème de rekeying est probable lorsque plusieurs indices concordent :

• Sophos Connect se déconnecte régulièrement après environ quatre heures.
• Après la déconnexion, les utilisateurs doivent confirmer à nouveau un OTP ou une MFA.
• La connexion est stable auparavant et fonctionne de nouveau après une nouvelle authentification.
• Les autres profils VPN ou connexions SSL VPN ne présentent pas ce comportement.
• Les horaires correspondent au rekeying de la phase 1 du profil IPsec attribué.
• Le journal VPN affiche au moment de la déconnexion des messages IKE, d’authentification ou de rekeying correspondants.

Vérifiez d’abord sous Remote access VPN > IPsec quel IPsec profile est sélectionné et si Disconnect when tunnel is idle est activé. Un Idle Timeout met uniquement fin aux connexions inactives après l’Idle session time interval configuré. Ce comportement est différent d’une déconnexion OTP récurrente pendant une utilisation active.

Si la connexion s’interrompt de manière aléatoire, ne fonctionne que dans certains réseaux ou ne transporte aucun trafic juste après son établissement, un dépannage VPN IPsec général est plutôt nécessaire.

Exclure d’abord Legacy Remote Access IPsec

Dans les environnements anciens en particulier, il faut d’abord déterminer quelle variante d’IPsec Remote Access est utilisée. Cet article traite de la configuration Remote Access IPsec actuelle avec Sophos Connect et des profils IPsec. Il ne constitue pas le bon point de départ si Legacy Remote Access IPsec est encore présent ou bloque une mise à niveau vers SFOS 22.0 MR1.

Orientation pratique :

• La connexion se déconnecte après une durée similaire, puis se rétablit : cet article est la prochaine étape appropriée.
• La mise à niveau vers SFOS 22.0 MR1 ou une version plus récente est bloquée en raison de Legacy IPsec : commencez par Migrer Legacy Remote Access IPsec avant SFOS 22 MR1.
• Le tunnel est connecté, mais les cibles internes ne sont pas accessibles : poursuivez plutôt avec Dépannage VPN IPsec de Sophos Firewall.
• Les utilisateurs doivent passer d’IPsec à SSL VPN, ZTNA ou à un autre modèle : consultez Sophos Connect ou SSL VPN : quelle solution d’accès distant choisir ?.

Cette distinction est importante, car l’ajustement de la Key life ne remplace pas un plan de migration. Si une ancienne configuration Legacy est encore présente sur le pare-feu, elle doit être correctement documentée, remplacée et supprimée avant une mise à niveau majeure du firmware.

Pourquoi le rekeying IKEv1 avec OTP interrompt le tunnel

Sophos Connect utilise un profil IKEv1 pour Remote Access IPsec. Dans de nombreux environnements, DefaultRemoteAccess est attribué. Ce profil détermine notamment la durée de vie de la Security Association de phase 1 et le moment où la renégociation commence.

Trois champs déterminent ce moment :

• Key life : durée de vie maximale de la SA de phase 1 en secondes.
• Re-key margin : période précédant l’expiration de la Key life pendant laquelle la renégociation commence.
• Randomize re-keying margin by : variation en pourcentage du moment du rekeying afin que tous les tunnels ne renégocient pas simultanément.

La capture existante documente un ancien état de DefaultRemoteAccess. Elle aide à repérer les champs, mais ne prouve pas les valeurs par défaut actuelles de votre build. L’aide SFOS 22 actuelle documente uniquement un intervalle de rekeying d’environ quatre heures pour le profil par défaut, et non une combinaison numérique universelle de Key life, Re-key margin et Randomize re-keying margin by. Les valeurs du profil réellement attribué et les horodatages de l’incident font foi.

La décision technique est importante : une valeur plus longue réduit les réauthentifications, mais prolonge aussi la durée de vie de l’IKE-SA. Il s’agit d’une décision d’exploitation et de sécurité, et non d’un simple réglage de confort.

Corréler les journaux avec la durée de connexion

Dans Log viewer, ouvrez la section VPN et comparez l’établissement de la connexion avec la déconnexion ultérieure du même utilisateur. Notez l’heure de début, l’utilisateur, l’adresse IP publique du client et l’heure de la nouvelle demande d’OTP. Relevez également l’état du client Sophos Connect au même moment.

Des messages tels que invalid SPI peuvent apparaître après l’expiration ou le remplacement de Security Associations. À eux seuls, ils ne prouvent toutefois pas ce problème. La combinaison d’une durée régulière, d’un profil IKEv1, d’une demande d’OTP et d’un rekeying de phase 1 correspondant dans le temps est plus probante. En cas de problèmes VPN récurrents, Sauvegarder les journaux de Sophos Firewall pour le support et l’analyse et Dépannage de Sophos Firewall : services et journaux peuvent également aider.

Adapter le profil IPsec via l’interface graphique

La méthode la plus propre consiste à ne pas modifier directement le profil attribué, mais à cloner précisément ce profil et à utiliser volontairement la nouvelle valeur pour Remote Access. Si DefaultRemoteAccess est attribué, clonez ce profil par défaut ; si un profil personnalisé est attribué, utilisez-le comme modèle.

Avant la modification, créez une sauvegarde de configuration et relevez les valeurs exactes de IPsec profile, Disconnect when tunnel is idle et Idle session time interval sous Remote access VPN > IPsec. Ouvrez ensuite le profil attribué sous Profiles > IPsec profiles et relevez, pour les phases 1 et 2, Key life, Re-key margin, Randomize re-keying margin by, Re-key connection et Dead peer detection. Ces valeurs observées constituent le précontrôle et le retour arrière ; elles ne doivent pas être recréées à partir de valeurs par défaut supposées.

Le chemin de menu actuel est :

Profiles > IPsec profiles

Procédure :

1. Cliquez sur Clone pour le profil attribué identifié lors du précontrôle.
2. Donnez au nouveau profil un nom explicite, par exemple RemoteAccess_OTP_12h.
3. Laissez Key exchange sur IKEv1 et gardez Re-key connection activé.
4. Sous Phase 1, vérifiez les valeurs Key life, Re-key margin et Randomize re-keying margin by.
5. Saisissez la Key life souhaitée. Pour cette solution de contournement, Sophos documente un maximum de 24 heures, soit 86400 secondes.
6. Sous Phase 2, vérifiez que la Key life indiquée reste inférieure à la valeur de la phase 1.
7. Sous Dead peer detection, utilisez un paramètre disponible pour Remote Access : désactivé ou When peer unreachable: Disconnect.
8. Enregistrez le profil.
9. Sous Remote access VPN > IPsec, sélectionnez le nouvel IPsec profile et enregistrez la configuration.
10. Déployez la configuration Sophos Connect actualisée et testez-la d’abord avec un utilisateur pilote.

Après la modification, il ne suffit pas d’enregistrer le pare-feu. Pour les fichiers .scx distribués manuellement, exportez un fichier actualisé sous Remote access VPN > IPsec avec Export connection, puis réimportez-le sur les clients. Avec un fichier .pro et Sophos Connect 2.1 ou une version ultérieure, le client récupère normalement les modifications depuis le VPN Portal. L’adresse de la passerelle et le port du VPN Portal ne doivent pas avoir changé.

Sophos Connect 2.1 présente toutefois deux limitations connues. NCL-1377 : une stratégie IPsec chargée via .pro peut ne pas se mettre à jour automatiquement pendant une connexion active ou si la stratégie du pare-feu change alors que le client est déconnecté. Déclenchez Update policy dans le client ; si IPsec et SSL VPN sont présents, NCL-1378 indique que l’option peut n’apparaître que sur la connexion SSL VPN. Comparez ensuite les détails d’un client pilote avec le nouveau profil. S’ils restent anciens, exportez et importez le .scx actuel.

Pour l’exploitation et les versions du client, consultez Vérifier la version du client Sophos Connect et la mettre à jour en toute sécurité. Pour les installations Windows, consultez Installer le client Sophos Connect sous Windows, et pour macOS, Installer le client Sophos Connect sous macOS.

Définir une durée de vie appropriée

Il n’existe aucune formule fiable permettant de calculer directement une valeur Key life unique à partir de la fréquence souhaitée des demandes d’OTP. La Key life est la durée de vie maximale de la SA ; le rekeying commence déjà pendant la Re-key margin et peut en outre être randomisé.

Par exemple, 43200 secondes correspondent à une Key life de douze heures. Selon la Re-key margin et la randomisation, la renégociation commence avant ce délai. Cette valeur ne doit donc pas être présentée comme garantissant une session utilisateur de douze heures. Sophos indique 24 heures comme limite maximale pour cette solution de contournement.

Avant la modification, il convient de clarifier les points suivants :

• Quelle durée de vie maximale de la clé IKE et quel intervalle de rekeying sont acceptables du point de vue de la sécurité ?
• La valeur est-elle adaptée aux horaires de travail, au fonctionnement par équipes et au processus du helpdesk ?
• OTP, RADIUS-MFA, Entra ID SSO ou une autre méthode d’authentification est-elle utilisée ?
• Existe-t-il des exigences de conformité relatives à la réauthentification ?
• Le rekeying ou la reconnexion fonctionne-t-il de manière fiable avec la version actuelle du client Sophos Connect ?

Pour les principes de base de la MFA sur le pare-feu, consultez Activer la MFA pour Sophos Firewall WebAdmin, VPN Portal et Remote Access. Si Microsoft Entra ID SSO est utilisé, tenez également compte de Configurer Microsoft Entra ID SSO pour Sophos Connect et VPN Portal.

Pourquoi une modification directe de la base de données n’est pas recommandée

Les anciens runbooks contiennent parfois des modifications directes dans l’Advanced Shell ou des commandes SQL exécutées sur la base de données du pare-feu. Cette méthode n’est pas recommandée pour l’exploitation normale.

Raisons :

• L’intervention contourne la validation WebAdmin normale.
• Des valeurs incorrectes peuvent perturber les profils VPN ou Remote Access.
• Les modifications sont plus difficiles à retracer.
• En cas de demande au support, une modification propre via l’interface graphique est plus facile à expliquer.
• Le comportement interne peut changer après une mise à jour.

La valeur doit donc être définie dans WebAdmin au moyen d’un profil IPsec personnalisé. Les modifications directes de la base de données doivent tout au plus être effectuées dans le cadre explicite d’une intervention du support Sophos, et non dans un guide d’administration standard.

Tester la modification pendant la fenêtre de rekeying

Après l’adaptation, effectuez un test limité avec des utilisateurs pilotes.

Points de contrôle :

1. Le nouveau profil est sélectionné dans Remote Access IPsec.
2. Le nouveau fichier .scx a été importé ou le provisionnement .pro a récupéré la modification.
3. La connexion s’établit correctement.
4. Les cibles internes sont accessibles.
5. Le DNS, le routage et les règles de pare-feu fonctionnent.
6. La connexion reste active jusqu’à la fenêtre de rekeying attendue.
7. Le rekeying n’entraîne aucune interruption imprévue ni boucle OTP inexpliquée.
8. Les journaux VPN montrent la renégociation attendue sans nouvelle erreur.

Si la connexion s’établit, mais qu’aucun trafic ne circule, le problème concerne plutôt les routes, les règles de pare-feu, le NAT ou le DNS. Dans ce cas, consultez Tester une règle de pare-feu avec Log Viewer, Policy Test et Packet Capture.

Revenir exactement à l’état précédent

En cas de nouvelles erreurs d’authentification, de déconnexions inattendues ou d’absence d’amélioration, sélectionnez sous Remote access VPN > IPsec le nom exact d’IPsec profile relevé avant la modification, puis enregistrez. Exportez et importez le .scx correspondant à cet ancien état, ou vérifiez l’actualisation de la stratégie avec .pro. Déconnectez et reconnectez une session pilote, puis contrôlez de nouveau l’établissement, les cibles internes, le DNS et le journal VPN.

Ne supprimez le profil cloné que lorsqu’aucune configuration Remote Access ne le référence et que le test de retour arrière a réussi. L’aide actuelle ne fournit pas de valeurs numériques par défaut prêtes à copier pour Key life, Re-key margin ou la randomisation. Le retour au DefaultRemoteAccess inchangé n’est donc correct que s’il était sélectionné auparavant ; si un profil personnalisé était actif, seul son nom relevé constitue le bon retour arrière.

Erreurs fréquentes

Pièges fréquents :

• Profil par défaut modifié directement : d’autres scénarios Remote Access peuvent être affectés involontairement. Il est préférable d’attribuer spécifiquement un profil cloné.
• Profil client non actualisé : lors d’une distribution manuelle du fichier .scx, les utilisateurs continuent d’utiliser les anciens paramètres. Avec un provisionnement .pro fonctionnel, les modifications ultérieures sont en revanche récupérées automatiquement.
• Valeur Key life trop longue : une réauthentification moins fréquente implique une durée de vie plus longue de l’IKE-SA. Les exigences de sécurité et d’exploitation doivent être évaluées ensemble.
• Seul le client a été réinstallé : le profil du pare-feu reste inchangé. Le profil du pare-feu et la configuration du client doivent être vérifiés conjointement.
• invalid SPI utilisé comme seule preuve : ce message peut également résulter de SA déjà remplacées. La durée de connexion, le rekeying IKE et la demande d’OTP doivent correspondre dans le temps.
• Base de données modifiée directement : cela augmente le risque de problèmes de support et de configuration. Pour l’exploitation normale, utilisez le profil via l’interface graphique.

Liste de contrôle opérationnelle

• Relever les utilisateurs concernés et les horaires correspondants.
• Vérifier si IPsec Remote Access est utilisé avec Sophos Connect.
• Rechercher dans les journaux VPN des indications relatives à IKE, SPI et au rekeying.
• Identifier le profil IPsec utilisé.
• Cloner le profil réellement attribué au lieu de le modifier directement.
• Relever les valeurs de phase 1 pour Key life, Re-key margin et la randomisation.
• Définir une valeur cible justifiée ne dépassant pas 24 heures.
• Attribuer le nouveau profil dans Remote Access IPsec.
• Redistribuer la configuration du client.
• Tester avec des utilisateurs pilotes et informer le helpdesk.
• Vérifier après quelques jours si le nombre de reconnexions OTP a diminué.

FAQ