Migrer Legacy Remote Access IPsec avant SFOS 22 MR1

Avec SFOS 22.0 MR1, Sophos a mis hors service Legacy Remote Access IPsec VPN. La simple présence d’une configuration Legacy sur le pare-feu bloque la mise à niveau vers SFOS 22.0 MR1 et les versions ultérieures. Elle doit être supprimée avant la mise à niveau, même si plus personne ne l’utilise actuellement pour se connecter.

Cet article explique comment identifier l’ancienne configuration avant une mise à niveau du firmware, la documenter proprement, la remplacer par une solution Remote Access actuelle, puis la supprimer seulement ensuite. Pour le contrôle général avant mise à niveau, consultez également Vérifier Sophos Firewall avant la mise à niveau vers SFOS 22.

Comprendre Legacy Remote Access IPsec

Au fil des années, Sophos a pris en charge plusieurs méthodes de Remote Access. Dans de nombreux environnements, il n’est donc pas immédiatement évident de savoir s’il s’agit d’une configuration IPsec actuelle, d’une ancienne entrée Legacy, de SSL VPN ou de Sophos Connect.

Pour la mise à niveau vers SFOS 22 MR1, les points suivants sont déterminants :

• Legacy Remote Access IPsec est l’ancien type de configuration susceptible de bloquer la mise à niveau.
• Remote Access IPsec actuel est la solution cible si IPsec doit continuer à être utilisé.
• SSL VPN peut constituer une alternative si IPsec est régulièrement bloqué dans les hôtels, les réseaux invités ou les environnements mobiles.
• ZTNA peut être pertinent lorsqu’il ne faut plus un VPN client complet, mais seulement un accès à certaines applications.

Cette distinction est importante pour l’exploitation. Un statut VPN au vert ou un client Sophos Connect fonctionnel ne prouve pas automatiquement qu’aucune configuration Legacy ne subsiste sur le pare-feu.

Les fichiers client aident également à faire la distinction :

• Pour une connexion Legacy, un fichier .tgb était extrait d’une archive .tar téléchargée, puis importé dans un client VPN tiers.
• La configuration Remote Access IPsec actuelle peut exporter un fichier .scx pour Sophos Connect. Celui-ci contient les paramètres généraux ainsi que les paramètres avancés.
• La présence d’un fichier .tgb actuel ne prouve pas à elle seule qu’il existe une configuration Legacy, car la page IPsec actuelle peut toujours l’exporter pour des clients tiers. L’entrée sous Remote access VPN > IPsec (legacy) est déterminante.

Un cas important lié à la restauration passe facilement inaperçu : les sauvegardes ou les configurations importées peuvent contenir Legacy Remote Access IPsec. Sophos restaure ou importe cette configuration, mais ne la migre pas vers le modèle Remote Access IPsec actuel. Après une restauration, un remplacement matériel ou un import de configuration, il faut donc vérifier de nouveau le blocage de la mise à niveau.

Quand effectuer la migration

La migration doit être terminée avant la mise à niveau prévue vers SFOS 22 MR1. Ce changement ne doit pas être réalisé seulement pendant la fenêtre de maintenance du firmware, car Remote Access implique souvent des utilisateurs, des certificats, MFA, DNS, des règles de pare-feu et des configurations client.

Déclencheurs typiques :

• Sophos Firewall doit être mis à jour vers SFOS 22.0 MR1 ou une version ultérieure.
• La page du firmware ou la documentation Sophos signale Legacy Remote Access IPsec.
• L’environnement contient d’anciens profils Sophos Connect qui n’ont plus été vérifiés depuis des années.
• Des utilisateurs signalent des problèmes Remote Access récurrents après des changements de profil ou de client.
• Remote Access doit de toute façon être réévalué avec MFA, Entra ID SSO, SSL VPN ou ZTNA.

Si Remote Access est critique pour l’activité, la migration doit être traitée comme un projet de changement à part entière. Une mise à niveau du firmware n’en est alors que le déclencheur, et non l’intégralité du travail.

Documenter la situation avant la migration

Il faut d’abord documenter l’état actuel. Cette étape est plus importante qu’il n’y paraît, car de nombreuses configurations VPN ne se limitent pas à un profil de tunnel. Elles impliquent souvent des groupes d’utilisateurs, des pools IP, des paramètres DNS, des règles de pare-feu, des exceptions NAT et des fichiers client.

Vérifier la configuration Legacy dans WebAdmin

Avant de planifier la solution cible, il faut déterminer précisément si Legacy Remote Access IPsec est réellement concerné. Ce contrôle doit être effectué non seulement avant la mise à niveau du firmware, mais aussi après une restauration, un remplacement matériel ou un import de configuration.

Procédure pratique :

1. Ouvrir Remote access VPN > IPsec (legacy) sur la version source encore prise en charge.
2. Vérifier si une connexion Legacy y est présente. Pour le blocage de la mise à niveau, peu importe qu’elle soit actuellement utilisée ou non.
3. Ouvrir Remote access VPN > IPsec et documenter séparément la configuration Remote Access IPsec actuelle.
4. Vérifier Authentication > Users et les groupes d’utilisateurs si des adresses IP statiques, des utilisateurs locaux ou d’anciennes affectations de groupes ont été utilisés.
5. Rechercher dans Rules and policies > Firewall rules les règles allant de la zone VPN vers LAN, DMZ ou WAN.
6. Vérifier sous Administration > Device access si IPsec, VPN Portal, DNS ou Ping sont accessibles depuis les zones nécessaires.
7. Ouvrir de nouveau la page du firmware et contrôler si un blocage de la mise à niveau est toujours affiché.

Si la section Legacy n’est plus visible alors que la mise à niveau reste bloquée, il ne faut pas supprimer des objets au hasard. Dans ce cas, une capture d’écran du message, une sauvegarde actuelle et une liste d’objets compréhensible sont plus importantes qu’un nettoyage précipité pendant la fenêtre de maintenance.

Il faut documenter au minimum :

• Utilisateurs et groupes : Quels utilisateurs peuvent utiliser Remote Access ? Des utilisateurs locaux, AD, RADIUS ou Entra ID sont-ils utilisés ?
• Authentification : Mot de passe, MFA, certificat, Preshared Key ou dépendances SSO.
• Pool IP : Quelles adresses les clients VPN reçoivent-ils ? Existe-t-il des conflits avec LAN, WLAN, VLAN ou d’autres VPN ?
• DNS : Quels serveurs DNS et domaines sont distribués aux clients ?
• Accès : Quels réseaux internes, serveurs et services doivent être accessibles ?
• Règles de pare-feu : Quelles règles autorisent le trafic de VPN vers LAN, DMZ ou WAN ?
• Distribution des clients : Où se trouvent les anciens fichiers .tgb, les profils Sophos Connect actuels (.scx ou .pro) ou les configurations SSL VPN ?
• Exploitation : Qui peut informer les utilisateurs, distribuer les profils et recevoir les signalements d’erreurs ?

S’il existe déjà des problèmes de routage ou de trafic à travers le tunnel, il ne faut pas les reprendre sans vérification dans la nouvelle configuration. Pour l’analyse, consultez Dépannage du VPN IPsec sur Sophos Firewall.

Choisir la solution cible

Il n’existe pas une seule solution correcte pour remplacer Legacy Remote Access IPsec. Le choix dépend des besoins réels des utilisateurs et du mode d’exploitation de l’environnement.

Remote Access IPsec actuel

Le Remote Access IPsec actuel est le choix logique si Sophos Connect doit continuer à être utilisé avec IPsec et si l’environnement fonctionne globalement bien ainsi. IPsec est souvent performant, mais peut poser problème dans des réseaux tiers restrictifs en raison de ports UDP bloqués ou de cas NAT particuliers.

Cette solution convient si :

• Sophos Connect est déjà déployé
• les utilisateurs travaillent avec Windows 10/11 ou macOS 13 et versions ultérieures
• IPsec était stable jusqu’à présent
• les réseaux internes doivent être accessibles via des règles de pare-feu classiques

Sophos Connect prend en charge le Remote Access IPsec actuel sur ces versions de Windows et macOS. Linux et les autres plateformes mobiles nécessitent un client tiers adapté ; iOS peut installer son propre profil IPsec depuis VPN Portal. Le guide existant Configurer Sophos Connect Client sur Sophos Firewall décrit la configuration complète.

SSL VPN

SSL VPN est pertinent lorsque Remote Access doit fonctionner aussi fiablement que possible à travers différents réseaux tiers. Selon l’environnement, SSL VPN peut être plus simple, mais soulève d’autres questions de performance et de client. Pour Windows, consultez le guide Installer Sophos Connect SSL VPN Client.

Cette solution convient si :

• les utilisateurs travaillent souvent dans des hôtels, des WLAN invités ou des réseaux d’entreprise tiers
• les connexions IPsec échouent régulièrement à cause de restrictions réseau
• des processus SSL VPN sont déjà établis
• les plateformes mobiles ou les clients OpenVPN tiers jouent un rôle

ZTNA ou Clientless Access

Si les utilisateurs n’ont besoin que de certaines applications web internes ou d’applications définies, il faut vérifier si un VPN full tunnel classique est encore la bonne solution. ZTNA ne remplace pas directement tous les scénarios VPN, mais peut constituer une meilleure architecture pour des cas d’usage clairement délimités.

Pour prendre cette décision, consultez d’abord Qu’est-ce que Zero Trust Network Access ? Principes, avantages et limites. Si Sophos ZTNA doit être utilisé, Sophos ZTNA Gateway Connector décrit le composant concret. Clientless Access ne constitue une alternative que pour les services adaptés accessibles par navigateur et ne remplace pas un accès général au réseau.

Mettre en place la nouvelle configuration Remote Access

La nouvelle configuration doit être préparée en parallèle avant de supprimer l’ancienne. L’objectif n’est pas de transférer tous les utilisateurs en même temps vers une configuration non testée.

Pour le Remote Access IPsec actuel, il ne suffit pas de créer un nouveau nom de profil. La procédure de migration doit reprendre ou redéfinir délibérément les paramètres essentiels :

1. Définir la variante cible : Remote Access IPsec actuel, SSL VPN, ZTNA ou une combinaison.
2. Sous Remote access VPN > IPsec, activer Remote Access et sélectionner l’Interface externe.
3. Utiliser un IPsec profile adapté. Remote Access accepte les profils IKEv1 pour lesquels Dead Peer Detection est désactivé ou défini sur Disconnect.
4. Définir Authentication type, les ID locale et distante ainsi que Allowed users and groups.
5. Sous Assign IP from, choisir une plage privée comprenant au moins un sous-réseau /24. Elle ne doit pas chevaucher SSL VPN, L2TP, PPTP, LAN, WLAN ni les réseaux Site-to-Site.
6. Définir DNS server 1, éventuellement DNS server 2, ainsi que les ressources internes nécessaires.
7. Choisir délibérément Split Tunnel ou Use as default gateway, puis configurer Prompt users for 2FA token selon la méthode MFA utilisée.
8. Sous Authentication > Groups, vérifier que Remote Access IPsec est autorisé pour le groupe d’utilisateurs réellement applicable. Cette option n’est pas activée automatiquement pour les groupes AD importés et les groupes migrés.
9. Sous Administration > Device access, autoriser IPsec depuis la zone WAN. VPN Portal n’est nécessaire que si les clients ou le provisionnement y accèdent ; DNS et Ping ne doivent être autorisés que si la conception concrète l’exige.
10. Créer des règles de pare-feu distinctes et clairement nommées pour le trafic VPN entrant et sortant, puis activer la journalisation.
11. Utiliser Export connection pour générer un fichier .scx destiné à Sophos Connect ou mettre à jour un provisionnement .pro existant.
12. Distribuer le profil de test à quelques utilisateurs pilotes, le tester sur au moins deux accès réseau différents, puis seulement planifier le déploiement.

MFA ne doit pas être considéré comme un détail facultatif pour Remote Access. Si le VPN est accessible dans le monde entier, MFA, des groupes d’utilisateurs correctement définis, la journalisation et une revue des paramètres Device Access vont de pair. L’article Configurer MFA sur Sophos Firewall couvre les principes de base.

Planifier la coexistence et le retour arrière

La nouvelle solution Remote Access doit d’abord être testée en parallèle de l’ancienne configuration. Cela permet de migrer progressivement les utilisateurs et de revenir en arrière de manière ciblée en cas d’erreur, sans modifier simultanément Remote Access, les règles de pare-feu, DNS, MFA et la distribution des clients pendant la même fenêtre de maintenance.

La coexistence doit toutefois être planifiée proprement. La nouvelle configuration ne doit pas utiliser le même pool IP, les mêmes règles de pare-feu aux noms peu explicites ni les mêmes noms de profil que l’ancienne configuration Legacy. Sinon, il sera ensuite impossible de déterminer dans Log Viewer quel accès a réellement connecté un utilisateur.

Avant le pilote, les points suivants doivent être définis :

• Groupe pilote : quelques utilisateurs techniquement joignables disposant d’appareils et de réseaux différents.
• Pool IP : plage dédiée sans chevauchement avec LAN, WLAN, Site-to-Site VPN ou l’ancien Remote Access.
• Règles de pare-feu : règles dédiées et clairement nommées pour le nouveau pool VPN.
• Profils client : nouveau nom de connexion permettant aux utilisateurs de distinguer la connexion Legacy de la connexion cible.
• Critère de retour arrière : définir à l’avance quand revenir à l’ancienne connexion.
• Fenêtre de support : le helpdesk ou un administrateur doit être joignable pendant le pilote.

Une procédure de retour arrière ne signifie pas que la configuration Legacy doit rester durablement en service. Elle sert uniquement à interrompre le pilote de manière contrôlée si l’authentification, MFA, DNS, le routage ou des applications centrales ne fonctionnent pas. Dès que la nouvelle solution est stable, l’ancienne configuration doit être supprimée et le blocage de la mise à niveau vérifié de nouveau.

Tests avant la suppression de la configuration Legacy

L’ancienne configuration ne doit être supprimée qu’une fois la solution de remplacement testée. Sinon, le problème de mise à niveau est certes résolu, mais Remote Access peut tomber en panne en production.

Test fonctionnel

Vérifier au minimum :

• la connexion avec un utilisateur de test fonctionne
• MFA ou SSO est demandé comme prévu
• le client reçoit une adresse IP VPN adaptée
• les noms DNS internes sont résolus
• les serveurs centraux sont accessibles
• le comportement Internet correspond à la conception : Split Tunnel ou Full Tunnel
• la déconnexion et la reconnexion fonctionnent

Test du pare-feu et du routage

Dans Log Viewer, vérifier si le trafic provenant de la zone VPN atteint les règles attendues. Si du trafic est rejeté, il ne faut pas vérifier uniquement la configuration VPN, mais aussi la règle de pare-feu, NAT, Route Precedence et le chemin de retour. Pour les connexions individuelles, l’article Tester une règle de pare-feu avec Log Viewer, Policy Test et Packet Capture est utile.

Test du client

Avec Sophos Connect, les profils existants ne doivent pas être écrasés silencieusement. Il vaut mieux effectuer un petit pilote avec des retours clairs :

• Le client importe-t-il la nouvelle configuration ?
• L’ancienne connexion est-elle remplacée de manière compréhensible pour les utilisateurs ?
• L’établissement de la connexion fonctionne-t-il après un redémarrage ?
• Les suffixes DNS, les routes et les connexions enregistrées sont-ils corrects ?
• Existe-t-il des différences entre Windows et macOS ?

Lors de la distribution d’un fichier .scx, toute modification ultérieure doit être de nouveau exportée et importée. Un provisionnement .pro déjà configuré peut récupérer automatiquement les modifications ultérieures tant que l’adresse de la passerelle et le port de VPN Portal restent accessibles et inchangés.

Avant un déploiement à grande échelle, il faut également vérifier la version du client utilisée. Pour cela, consultez Vérifier et mettre à jour Sophos Connect Client en toute sécurité.

Supprimer la configuration Legacy

Lorsque la nouvelle solution a été testée en production, la configuration Legacy peut être supprimée. Avant cela, il faut créer une nouvelle sauvegarde. C’est particulièrement important si des règles de pare-feu, des groupes d’utilisateurs ou des serveurs d’authentification sont également modifiés dans le cadre du même changement.

Procédure pratique :

1. Créer une nouvelle sauvegarde.
2. Informer les utilisateurs actifs de la fenêtre de maintenance.
3. Laisser la nouvelle configuration Remote Access active.
4. Supprimer Legacy Remote Access IPsec dans WebAdmin.
5. Vérifier les dépendances des anciens profils, pools IP et règles qui ne sont plus nécessaires.
6. Ouvrir de nouveau la page du firmware et contrôler si le blocage de la mise à niveau a disparu.
7. Documenter le résultat.

Ne supprimez pas immédiatement tout ce qui paraît ancien. D’anciennes règles de pare-feu, des hôtes ou des groupes peuvent également être utilisés pour Site-to-Site VPN, SSL VPN ou à d’autres fins. Vérifiez d’abord les dépendances, puis effectuez le nettoyage.

Après une restauration ou un import de configuration, le contrôle doit être répété. Une sauvegarde peut contenir d’anciens objets Legacy sans qu’une configuration Remote Access IPsec actuelle en résulte automatiquement. Pour l’exploitation et la documentation, il est donc essentiel de savoir si la configuration cible en production a réellement été reconstruite, testée et distribuée.

Dépannage

La mise à niveau reste bloquée

Si la mise à niveau reste bloquée alors que la configuration Legacy visible a été supprimée, ouvrez d’abord de nouveau la section du firmware et vérifiez encore une fois Remote access VPN > IPsec (legacy). Ne supprimez pas au hasard des hôtes, des groupes ou des profils IPsec actuels. Si la configuration Legacy détectée reste incertaine, préparez un Sophos Support Case avec une capture d’écran du message de mise à niveau, la version source et une sauvegarde actuelle.

La question de la configuration Legacy réapparaît après une restauration

Après une restauration, un remplacement matériel ou l’import d’une ancienne configuration, il faut vérifier de nouveau Remote Access. Ce qui compte n’est pas qu’un changement ait été terminé par le passé, mais ce qui existe dans la configuration actuellement en service. D’anciennes sauvegardes peuvent réintroduire des objets Remote Access historiques ou déclencher une nouvelle vérification du chemin de mise à niveau.

Les utilisateurs ne peuvent pas se connecter

En cas de problèmes de connexion, vérifiez d’abord l’authentification, MFA, le groupe d’utilisateurs et VPN-Policy. Si RADIUS, AD ou Entra ID est impliqué, testez la connexion au serveur séparément du VPN. Un problème VPN n’est pas toujours un problème IPsec.

La connexion est établie, mais les systèmes internes ne sont pas accessibles

La cause se trouve alors souvent dans les règles de pare-feu, NAT, DNS ou le routage. Vérifiez si le client reçoit une adresse IP VPN adaptée, si les noms internes sont correctement résolus et si le trafic atteint la règle attendue dans Log Viewer.

Certains réseaux fonctionnent, d’autres non

Dans ce cas, des réseaux Split Tunnel, des routes IPsec, des routes statiques ou des routes de retour manquantes sont souvent en cause. Dans les scénarios IPsec, Route IPsec sur Sophos Firewall est un article complémentaire utile.

Liste de contrôle

Avant le déploiement

• Legacy Remote Access IPsec identifié
• utilisateurs, groupes, pool IP, DNS et règles de pare-feu documentés
• solution cible choisie : IPsec actuel, SSL VPN, ZTNA ou une combinaison
• MFA et authentification vérifiés
• Device Access vérifié selon les besoins : IPsec sur WAN, VPN Portal pour la distribution ou le provisionnement, DNS et Ping uniquement si nécessaire
• coexistence et critère de retour arrière définis
• utilisateurs de test définis
• sauvegarde créée

Pendant le déploiement

• nouvelle configuration testée avec des utilisateurs pilotes
• profils client distribués
• Log Viewer et règles de pare-feu concernées vérifiés
• procédure de retour arrière communiquée
• retours des utilisateurs recueillis

Après la migration

• configuration Legacy supprimée
• blocage de la mise à niveau vérifié de nouveau
• scénario de restauration et d’import documenté
• dépendances des anciens profils et règles vérifiées
• documentation mise à jour
• mise à niveau du firmware planifiée seulement ensuite

FAQ