Migrer l'IPsec Remote Access Legacy avant SFOS 22 MR1
Avec SFOS 22.0 MR1, Sophos a définitivement retiré le Legacy Remote Access IPsec VPN du chemin de mise à niveau supporté. Les pare-feux sur lesquels cette ancienne configuration IPsec Remote Access existe encore ne peuvent pas être mis à jour vers SFOS 22.0 MR1 ou une version ultérieure.
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 la vérification générale avant mise à niveau, consultez également Vérification avant la mise à niveau vers SFOS 22 de Sophos Firewall.
De quoi parle l’IPsec Remote Access Legacy
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, le point décisif est surtout le suivant :
- Legacy Remote Access IPsec est l’ancien type de configuration qui peut bloquer la mise à niveau.
- Remote Access IPsec actuel est le chemin cible si IPsec doit continuer à être utilisé.
- SSL VPN peut être 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 un accès à des applications individuelles.
La différence est importante en exploitation. Un statut VPN vert ou un client Sophos Connect fonctionnel ne prouve pas automatiquement qu’aucune configuration Legacy n’est encore présente sur le pare-feu.
Un cas de restauration important est facilement oublié : les sauvegardes ou configurations importées peuvent contenir l’IPsec Remote Access Legacy, mais cette configuration Legacy n’est pas migrée automatiquement. Après une restauration, un remplacement matériel ou un import de configuration, il faut donc revérifier ce point, même si le pare-feu semblait déjà nettoyé auparavant.
Quand migrer
La migration doit être terminée avant la mise à niveau planifiée vers SFOS 22 MR1. Ce changement ne doit pas être traité 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 l’IPsec Remote Access Legacy.
- 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’est alors que le déclencheur, pas tout le périmètre de travail.
Documenter 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 cible, il faut déterminer proprement si l’IPsec Remote Access Legacy est réellement concerné. Cette vérification doit être faite 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 :
- Ouvrir Remote access VPN > IPsec (legacy) si ce menu est visible dans la version SFOS installée.
- Vérifier si l’IPsec Remote Access Legacy est activé ou si des objets de configuration existent encore.
- Ouvrir Remote access VPN > IPsec et documenter séparément la configuration IPsec Remote Access actuelle.
- 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.
- Rechercher dans Rules and policies > Firewall rules les règles allant de la zone
VPNversLAN,DMZouWAN. - Vérifier sous Administration > Device access si IPsec, VPN Portal, DNS ou Ping sont accessibles depuis les zones nécessaires.
- Rouvrir la page du firmware et contrôler si un blocage de mise à niveau est encore affiché.
Si la zone Legacy n’est plus visible, mais 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 :
| Domaine | Ce qui doit être vérifié |
|---|---|
| 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 client | Où se trouvent les profils Sophos Connect ou configurations SSL VPN actuels ? |
| Exploitation | Qui peut informer les utilisateurs, distribuer les profils et recevoir les incidents ? |
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 VPN IPsec sur Sophos Firewall.
Choisir le chemin cible
Il n’existe pas un seul remplacement correct pour l’IPsec Remote Access Legacy. Le choix dépend de ce dont les utilisateurs ont réellement besoin et de la manière dont l’environnement est exploité.
Remote Access IPsec actuel
Le Remote Access IPsec actuel est naturel 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 à cause de ports UDP bloqués ou de cas NAT particuliers.
Ce chemin convient bien si :
- Sophos Connect est déjà déployé
- les utilisateurs travaillent principalement avec Windows ou macOS
- IPsec était stable dans l’utilisation précédente
- les réseaux internes doivent être accessibles via des règles de pare-feu classiques
Le guide existant Configurer Sophos Connect Client sur Sophos Firewall peut servir de base, mais doit être confronté aux versions SFOS actuelles et à votre propre conception d’authentification.
SSL VPN
SSL VPN est pertinent lorsque Remote Access doit fonctionner aussi robustement que possible à travers différents réseaux tiers. Selon l’environnement, SSL VPN peut être plus simple, mais il soulève d’autres questions de performance et de client. Pour Windows, consultez le guide Installer le client Sophos Connect SSL VPN.
Ce chemin convient bien 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 existent déjà
- les plateformes mobiles ou des clients OpenVPN tiers jouent un rôle
ZTNA ou Clientless Access
Si les utilisateurs n’ont besoin que d’applications web internes individuelles 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 chaque scénario VPN, mais peut être une meilleure architecture dans des cas d’usage clairement délimités.
L’article existant Sophos ZTNA Gateway Connector est un bon point de départ. Pour de simples accès web, Clientless Access peut aussi être pertinent si les exigences correspondent.
Construire 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 déplacer tous les utilisateurs en même temps vers une configuration non testée.
Procédure recommandée :
- Définir la variante cible : Remote Access IPsec actuel, SSL VPN, ZTNA ou combinaison.
- Choisir un nouveau pool IP et vérifier les chevauchements.
- Définir la source d’authentification et MFA.
- Affecter les utilisateurs ou groupes nécessaires.
- Définir les serveurs DNS et les domaines internes.
- Créer les règles de pare-feu pour les nouvelles sources VPN.
- Générer un profil de test pour quelques utilisateurs.
- Tester la connexion sur au moins deux accès réseau différents.
- Planifier seulement ensuite la communication utilisateur et le déploiement.
MFA ne doit pas être traité comme un détail optionnel pour Remote Access. Si le VPN est accessible dans le monde entier, MFA, des groupes d’utilisateurs propres, la journalisation et une revue des paramètres Device Access vont ensemble. L’article Configurer MFA sur Sophos Firewall couvre les bases.
Planifier la coexistence et le retour arrière
La nouvelle solution Remote Access doit d’abord être testée à côté de l’ancienne configuration. Cela permet de migrer les utilisateurs progressivement et, en cas d’erreur, de revenir de manière ciblée sans modifier Remote Access, les règles de pare-feu, DNS, MFA et la distribution client dans 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 nommées de manière floue ni les mêmes noms de profils que l’ancienne configuration Legacy. Sinon, le Log Viewer ne permettra plus de savoir ultérieurement quel accès a réellement connecté un utilisateur.
Avant le pilote, ces points doivent être définis :
| Point | Recommandation |
|---|---|
| Groupe pilote | quelques utilisateurs techniquement joignables avec différents appareils et réseaux |
| 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 profil pour que les utilisateurs distinguent l’ancienne et la nouvelle connexion |
| 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 |
Un chemin de retour arrière ne signifie pas exploiter durablement la configuration Legacy. Il sert uniquement à interrompre le pilote de manière contrôlée si l’authentification, MFA, DNS, le routage ou les applications centrales ne fonctionnent pas. Dès que la nouvelle solution est stable, l’ancienne configuration doit être supprimée et le blocage de mise à niveau revérifié.
Tests avant la suppression de la configuration Legacy
L’ancienne configuration ne doit être supprimée qu’une fois le remplacement testé. 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 IP VPN adaptée
- les noms DNS internes sont résolus
- les serveurs centraux sont accessibles
- le comportement Internet correspond au design : Split Tunnel ou Full Tunnel
- la déconnexion et la reconnexion fonctionnent
Test pare-feu et routage
Dans le Log Viewer, vérifier si le trafic de la zone VPN atteint les règles attendues. Si le 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 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, routes et connexions enregistrées sont-ils corrects ?
- Existe-t-il des différences entre Windows et macOS ?
Avant un déploiement large, il faut aussi vérifier la version client utilisée. Pour cela, consultez Vérifier et mettre à jour en sécurité la version de Sophos Connect Client.
Supprimer la configuration Legacy
Lorsque la nouvelle solution est testée en production, la configuration Legacy peut être supprimée. Avant cela, il faut encore créer une sauvegarde actuelle. C’est particulièrement important si des règles de pare-feu, des groupes d’utilisateurs ou des serveurs d’authentification sont également adaptés dans le même changement.
Procédure pratique :
- Créer une sauvegarde fraîche.
- Informer les utilisateurs actifs de la fenêtre de maintenance.
- Laisser la nouvelle configuration Remote Access active.
- Supprimer Legacy Remote Access IPsec dans WebAdmin.
- Vérifier les anciens profils, pools IP et règles qui ne sont plus nécessaires.
- Rouvrir la page du firmware et contrôler si le blocage de mise à niveau a disparu.
- Documenter le résultat.
Ne supprimez pas immédiatement tout ce qui paraît ancien. D’anciennes règles de pare-feu, hôtes ou groupes peuvent aussi être utilisés pour Site-to-Site VPN, SSL VPN ou d’autres usages. Vérifiez d’abord les dépendances, puis nettoyez.
Après une restauration ou un import de configuration, la vérification doit être répétée. 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 décisif de savoir si la configuration cible productive a réellement été reconstruite, testée et distribuée.
Troubleshooting
La mise à niveau reste bloquée
Si la mise à niveau reste bloquée alors que la configuration Legacy visible a été supprimée, rechargez d’abord le pare-feu ou rouvrez la zone Firmware. Vérifiez ensuite si tous les objets Legacy Remote Access ont réellement été supprimés. Si l’objet bloquant reste incertain, il faut préparer un Sophos Support Case avec une capture d’écran du message de mise à niveau et une sauvegarde actuelle.
La question 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 revérifier 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 la 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 IP VPN adaptée, si les noms internes sont résolus correctement et si le trafic atteint la règle attendue dans le Log Viewer.
Certains réseaux fonctionnent, d’autres non
Dans ce cas, des réseaux Split Tunnel, routes IPsec, routes statiques ou routes de retour manquantes sont souvent en cause. Dans les scénarios IPsec, Route IPsec sur Sophos Firewall est un article complémentaire utile.
Checklist
Avant le déploiement
- Legacy Remote Access IPsec identifié
- utilisateurs, groupes, pool IP, DNS et règles de pare-feu documentés
- chemin cible choisi : IPsec actuel, SSL VPN, ZTNA ou combinaison
- MFA et authentification vérifiés
- Device Access pour IPsec, VPN Portal, DNS et Ping vérifié
- 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
- chemin de retour arrière communiqué
- retours utilisateurs collectés
Après la migration
- configuration Legacy supprimée
- blocage de mise à niveau revérifié
- scénario de restauration et d’import documenté
- anciens profils et règles vérifiés pour leurs dépendances
- documentation mise à jour
- mise à niveau du firmware planifiée seulement ensuite