Configurer et tester l’accès distant L2TP sur Sophos Firewall

L’accès distant L2TP reste disponible sur Sophos Firewall, mais il ne devrait pas être automatiquement le premier choix pour de nouveaux endpoints administrés. Sophos Connect avec IPsec ou SSL VPN se gère plus facilement de manière centralisée et fournit le parcours client Sophos le plus complet. L2TP reste utile lorsqu’un système d’exploitation doit utiliser son client VPN natif ou qu’un environnement compatible existant doit être maintenu de façon contrôlée.

Positionnement pour les nouveaux environnements : Les pages d’aide comparées pour SFOS 22 et 23 présentent L2TP comme un type d’accès distant configurable. Cela atteste des fonctionnalités documentées, mais ne garantit ni leur disponibilité dans chaque build ni leur maintien dans les futures versions majeures. Avanet ne recommande pas L2TP comme nouveau standard pour les clients administrés. Aucun nouvel accès L2TP ne devrait être déployé sans exigence concrète liée à un environnement existant ou à la compatibilité.

L2TP définit seulement le tunnel, pas la sécurité requise. Sur Sophos Firewall, une stratégie IPsec protège la connexion. Le profil IPsec, l’authentification, la clé prépartagée ou le certificat ainsi que la configuration du client doivent donc correspondre. Un état Active vert signifie uniquement que la stratégie est activée ; seuls l’état Connection et un trafic réel confirment le tunnel.

⚠️ La Route Precedence exigée par Sophos pour L2TP place globalement vpn avant Static et SD-WAN Policy Routes. Une nouvelle stratégie L2TP avec un peer générique peut également affecter des clés prépartagées existantes. Avant toute modification, documenter l’ordre actuel, un accès d’administration indépendant ainsi que tous les autres chemins VPN, Static et SD-WAN.

L2TP en huit étapes

1. Confirmer que L2TP est réellement nécessaire et que le client, le profil IPsec et l’authentification sont compatibles.
2. Planifier une plage de leases privée sans chevauchement, des serveurs DNS internes et un groupe d’utilisateurs restreint.
3. Sous Remote access VPN > L2TP > L2TP global settings, activer L2TP et ajouter les utilisateurs.
4. Créer une stratégie L2TP avec le profil IPsec, le port WAN, l’authentification et NAT Traversal appropriés.
5. Sous Administration > Device access, autoriser le service IPsec pour l’accessibilité WAN requise.
6. Enregistrer la Route Precedence actuelle et placer vpn en premier lors d’une modification contrôlée.
7. Créer une règle de firewall restrictive et journalisée de la zone VPN vers les destinations internes réellement nécessaires.
8. Avec un client pilote externe, valider l’authentification, l’adresse attribuée, DNS, la règle, le chemin retour et un test négatif.

Quand L2TP convient

L2TP peut être utile pour les clients natifs des systèmes d’exploitation ou les appareils existants sur lesquels Sophos Connect n’est pas prévu. Il constitue aussi un choix raisonnable lorsqu’un petit environnement L2TP déjà documenté doit continuer à fonctionner sans logiciel client supplémentaire.

Pour un nouveau déploiement standard, Sophos Connect avec IPsec ou SSL VPN est généralement plus approprié. La distribution des profils, le diagnostic du client et le parcours de support propre à Sophos y sont plus clairs. Pour certaines applications, Clientless SSL VPN permet un accès par navigateur sans tunnel réseau complet. PPTP n’est pas une solution de repli moderne : le protocole ne définit lui-même ni chiffrement ni authentification ; la possibilité de choisir une méthode de connexion n’en fait pas une nouvelle architecture cible sûre.

Trois limites doivent être claires avant la configuration :

• Sur Sophos Firewall, L2TP utilise une plage d’adresses globale partagée et des paramètres DNS communs à toutes les stratégies L2TP.
• Les groupes importés depuis Active Directory ou Microsoft Entra ID ne sont pas automatiquement activés pour L2TP. Ils doivent être ajoutés explicitement avec Add members.
• L2TP et PPTP ne prennent en compte que le groupe principal pertinent lors de l’évaluation des appartenances. Une appartenance supplémentaire ne prouve donc pas à elle seule l’autorisation. Gérer correctement les groupes d’utilisateurs et le groupe principal explique ce fonctionnement.

Exemple et préparation

L’exemple connecte un client externe à un réseau d’applications interne. Ces valeurs sont volontairement des valeurs de documentation et doivent être adaptées à l’environnement réel :

• plage L2TP : 10.250.30.10 à 10.250.30.100 dans 10.250.30.0/24
• serveur DNS interne : 10.10.10.10
• groupe autorisé : L2TP_Users
• nom de la stratégie : L2TP_Remote_Access
• profil IPsec : DefaultL2TP comme point de départ du test de compatibilité
• réseau de destination interne : 10.10.10.0/24
• service d’exemple : HTTPS

La plage 10.250.30.0/24 est uniquement un réseau privé d’exemple. Elle ne doit chevaucher aucun réseau LAN, VLAN, Site-to-Site ou domestique, ni les plages de leases utilisées par Remote Access IPsec, SSL VPN ou PPTP. Sophos autorise au maximum 254 adresses pour Assign IP from, dans un sous-réseau /24 ou plus petit.

Avant de commencer, vérifier également les points suivants :

• Un profil IPsec approprié correspond aux paramètres pris en charge par le client natif.
• L’adresse publique ou le FQDN du port WAN sélectionné est accessible depuis le client.
• L’heure système, DNS et la chaîne de certificats sont corrects lorsqu’un certificat est utilisé.
• L’utilisateur ou le groupe existe et la bonne méthode d’authentification est inscrite sous Authentication > Services > VPN (IPsec/dial-in/L2TP/PPTP) authentication methods.
• La sortie actuelle de system route_precedence show et une commande de rollback correspondante sont documentées.
• WebAdmin ou la console reste accessible par un chemin d’administration indépendant.

La source d’authentification et le client doivent prendre en charge la même méthode : SFOS indique PAP, CHAP ou MSCHAPv2 pour Local et RADIUS, uniquement PAP pour Active Directory et LDAP, et PAP ou CHAP pour TACACS+. Avant le déploiement, vérifier la méthode commune avec le client natif. La protection IPsec externe reste obligatoire pour L2TP ; cette matrice de compatibilité ne constitue pas une recommandation pour PPTP ni pour l’utilisation de PAP sans protection.

Limites de version et de client

Ce guide est conçu pour SFOS 22.0 MR2 Build 546 et l’interface décrite dans l’aide en ligne 22.0. L2TP est disponible dans cette version. Le contrôle de mise à niveau SFOS 22 d’Avanet regroupe les blocages actuels et les chemins pris en charge ; avant chaque migration, y comparer le build source concret au build cible. Il n’existe pas de matrice de compatibilité complète pour les clients L2TP natifs. Le guide 22.0 cite uniquement Windows 10 comme exemple concret. Cela ne prouve pas la compatibilité d’autres versions, actuelles ou futures, des systèmes d’exploitation.

Les pages d’aide L2TP complètes pour SFOS 22 et 23 décrivent les mêmes paramètres globaux, champs de stratégie et étapes de configuration. Ne pas transférer l’exemple SFOS 22 à SFOS 23 sans confirmer les paramètres et le fonctionnement du client. La matrice des plateformes pour Sophos Connect, IPsec et SSL VPN dans la FAQ sur l’accès distant n’est pas non plus une matrice de compatibilité L2TP ; pour un remplacement, suivre le comparatif des clients lié plus haut et la procédure IPsec ou SSL VPN correspondante.

Chaque version d’OS réellement utilisée doit donc être testée séparément avec le profil IPsec, le serveur d’authentification et le type d’ID prévus. Le maximum de 254 adresses de la plage n’est qu’une limite d’adressage, pas la promesse d’autant de sessions simultanées. L’aide publique 22.0 n’indique pas de limite L2TP générale. Valider capacité et stabilité sur le modèle de firewall concerné avec le nombre prévu de connexions simultanées.

L’aide actuelle décrit les valeurs disponibles, mais ne définit aucune valeur par défaut universelle pour Gateway type, Authentication type, Allow NAT traversal ou Disconnect when tunnel is idle dans les configurations existantes ou migrées. Relever ces champs avant et après une mise à niveau au lieu de les reconstruire à partir d’une valeur supposée.

Configurer et vérifier le client Windows natif

Sous Windows, créer la connexion via Paramètres > Réseau et Internet > VPN > Ajouter un VPN. Sélectionner Windows (intégré) comme fournisseur VPN, saisir le FQDN public ou l’adresse WAN du firewall dans Nom ou adresse du serveur, puis choisir L2TP/IPsec avec clé prépartagée ou l’option de certificat correspondant au profil du firewall comme type de VPN. La clé prépartagée doit correspondre au PSK de la stratégie L2TP. Utiliser comme informations de connexion le nom d’utilisateur et le mot de passe d’un compte autorisé sous Add members ; documenter ensemble le type de VPN, la méthode de connexion, les ID et la version du client.

Effectuer le premier test depuis un réseau externe. Après la connexion, utiliser ipconfig /all pour contrôler l’adresse de la plage L2TP et les serveurs DNS prévus, puis tester la résolution de noms interne et l’accès HTTPS autorisé. Si l’établissement du tunnel échoue, comparer d’abord le nom du serveur, le mode PSK ou certificat, la méthode de connexion et le profil IPsec convenu, puis corréler l’horodatage avec l2tpd.log et les journaux IPsec. Chaque version de Windows utilisée reste une combinaison client à valider séparément.

Configurer les paramètres L2TP globaux

Sous Remote access VPN > L2TP > L2TP global settings, activer Enable L2TP. Dans cet exemple, saisir 10.250.30.10 à 10.250.30.100 dans Assign IP from. Sélectionner 10.10.10.10 comme Primary DNS server si ce serveur peut résoudre les noms internes. Le champ DNS est facultatif : sélectionner le serveur dans la liste ou saisir son adresse via Other. Ne définir Secondary DNS server, Primary WINS server et Secondary WINS server que si l’environnement en a réellement besoin ; WINS ne remplace pas DNS.

L’option Allow leasing IP address from RADIUS server for L2TP, PPTP, and Sophos Connect client n’est utile que si le serveur RADIUS fournit de manière fiable une adresse adaptée. S’il ne renvoie aucune adresse, le firewall utilise d’abord une adresse statique configurée pour l’utilisateur, puis la plage globale. L’attribution RADIUS et le chemin de repli doivent donc tous deux être planifiés sans chevauchement. Configurer RADIUS sur Sophos Firewall décrit la configuration du serveur.

Sélectionner ensuite le groupe L2TP_Users via Add members, confirmer avec Add et vérifier avec Show members. Pour un utilisateur d’annuaire, une importation de groupe réussie ne suffit pas. Un utilisateur pilote doit réellement appartenir au groupe autorisé, et ce groupe doit être pris en compte comme groupe principal lors de l’évaluation L2TP.

Après avoir modifié les paramètres globaux et les membres, cliquez sur Apply. Vérifiez de nouveau les valeurs globales enregistrées et Show members. L’action Save de la stratégie L2TP constitue une étape distincte.

Limites de l’automatisation via l’API XML

Les étapes de l’interface ne constituent pas une requête XML API prête à l’emploi. Les pages de l’API comparées pour SFOS 22 et 23 séparent, sous L2TPConfiguration, les valeurs globales dans L2TPSettings des membres dans L2TPMembers avec UserName. Contrairement à l’interface, le tableau indique que PrimaryDNSServer est un champ obligatoire contenant une adresse IPv4. Le caractère facultatif du champ DNS dans l’interface ne prouve donc pas que ce paramètre de l’API peut être omis. L2TPGeneralSettings et LeaseIPFromRadiusServer y sont indiqués comme facultatifs, avec Disable comme valeur par défaut documentée ; cela n’établit aucun comportement vérifié en cas d’omission. Avant toute automatisation, clarifier le contrat de l’API du build installé sans deviner un encodage DNS vide. Relire ensuite les valeurs globales prévues et les appartenances ; la procédure dans l’interface et le mécanisme de repli RADIUS décrits plus haut restent distincts.

Pour la stratégie enregistrée décrite ci-dessous, l’exemple de l’API présente L2TPConnection avec Configuration ; à côté figurent les branches de commande Connection, DisConnection, Active et DeActive, chacune avec Name. L’enregistrement, la connexion, la déconnexion et l’activation ne correspondent donc pas à la même identité ni à la même action. Les icônes de l’interface ne suffisent pas à établir une requête API exécutable. En outre, l’exemple et le tableau des champs se contredisent : RemoteHost contient un nom d’hôte ou une adresse IP dans l’exemple, tandis que le tableau autorise IPv4 ou * ; AliasLocalWANPort représente uniquement un alias WAN dans l’exemple, mais est obligatoire dans le tableau. Pour DisconnectOnIdleInterval, le tableau indique une valeur par défaut de 0, tout en spécifiant une plage de 120 à 999 ; 600 est uniquement la valeur de l’exemple. Ne pas en déduire une signification pour zéro ni des valeurs de remplacement sûres. Avant toute modification via l’API, clarifier ces points pour le build concerné et vérifier l’accès d’administration indépendant ainsi que les effets sur les PSK partagés des stratégies génériques, comme indiqué plus haut.

Lors du retrait ultérieur de la configuration, il faut également distinguer la suppression d’une connexion enregistrée de sa désactivation et de l’arrêt global de L2TP. Commencer par inventorier la configuration existante, désactiver la connexion prévue et vérifier les dépendances. Delete L2TP Connection exige le Name enregistré exact (première lettre A-Za-z, puis A-Za-z0-9_, au maximum 50 caractères) ; la page ne fournit aucun exemple de requête. Ses correspondances de statut 200/L2TPDeleteSuccess, 203/L2TPConnInUse et 500/L2TPDeleteFail renvoient à des identifiants Message non résolus, et non à des textes de message confirmés ou à une classification HTTP. En particulier, ne pas considérer 203 comme un succès générique de suppression de classe 2xx. Une fois la requête de suppression clarifiée, vérifier de nouveau le nom exact de la cible et confirmer que les accès de production toujours nécessaires sont préservés ; ne pas deviner une enveloppe de requête de suppression ni un nettoyage automatique ultérieur.

Adresse statique par utilisateur et dépendances PPTP existantes

Les champs d’attribution d’adresse propres à l’utilisateur se trouvent sous Authentication > Users > [Utilisateur], dans les paramètres d’accès distant. L2TP autorise l’accès L2TP et permet de saisir l’adresse IP à attribuer à l’utilisateur distant. PPTP dispose de son propre commutateur et de son propre champ de saisie pour l’adresse IP à attribuer. Il s’agit de deux paramètres de compte distincts, et non de la plage globale ou d’une attribution d’adresse IP SSL VPN. Pour gérer l’utilisateur local et son mot de passe, suivre Créer des utilisateurs locaux sur Sophos Firewall. Uniquement pour un accès existant justifié, prévoir une adresse unique sans conflit, enregistrer avec Save, puis vérifier l’adresse effectivement attribuée et le chemin retour lors de la prochaine connexion depuis un réseau externe. Avec l’attribution par RADIUS, l’adresse de l’utilisateur reste le mécanisme de repli décrit plus haut si RADIUS ne fournit aucune adresse ; un commutateur de compte ne remplace ni l’autorisation via Add members ni la règle de firewall.

Première connexion avant le tunnel : Après l’activation de L2TP ou de PPTP, l’aide relative à l’ajout d’utilisateurs pour SFOS 22 et 23 exige que les membres de la stratégie se connectent d’abord au VPN portal et créent un mot de passe avant d’établir une connexion VPN. Vérifier cette procédure initiale documentée avec un compte pilote, pour le build et le serveur d’authentification utilisés. Ne pas réinitialiser les mots de passe existants sans motif confirmé ni remplacer systématiquement une authentification d’annuaire fonctionnelle par des mots de passe locaux. Vérifier séparément l’accessibilité du portail et VPN portal authentication methods, indépendamment de la méthode utilisée pour le tunnel ; il n’est pas nécessaire d’ouvrir WebAdmin depuis le WAN à cette fin.

Pour inventorier un accès PPTP déjà existant, on trouve sous Remote access VPN > PPTP les champs Enable PPTP, Assign IP from, l’option commune d’attribution d’adresse par RADIUS, ainsi que le serveur DNS principal et les serveurs DNS secondaires et WINS facultatifs. Le bail reste valable pendant la connexion ; la plage privée se situe dans un sous-réseau /24 ou plus petit et contient au maximum 254 adresses. Elle ne doit pas chevaucher les plages Remote Access IPsec et SSL VPN. L’aide décrit Apply pour les valeurs globales ainsi que Add members et Show members pour l’autorisation des utilisateurs ; ici aussi, l’importation d’un groupe AD ou Entra ID n’autorise pas automatiquement l’accès. Ces champs sont uniquement relevés dans la configuration existante pour la migration et le dépannage, et ne constituent pas une recommandation d’activer PPTP. Les méthodes documentées PAP, CHAP et MS-CHAPv2 ne constituent pas un standard de sécurité moderne ; prévoir le remplacement avec IPsec, SSL VPN ou un accès limité aux applications.

Créer la stratégie L2TP

Sous Remote access VPN > L2TP, utiliser Add pour créer la stratégie L2TP_Remote_Access.

Profil et comportement au démarrage

Sous Profile, sélectionner le profil IPsec correspondant aux clients. Dans l’exemple, le profil existant DefaultL2TP sert de point de départ au test de compatibilité. Ses algorithmes et lifetimes doivent néanmoins être comparés aux valeurs prises en charge par le client ; un nom contenant Default n’est pas une garantie de sécurité durable. Les deux valeurs de Gateway type ont des conséquences différentes en exploitation :

• Respond only maintient la stratégie prête après un redémarrage afin de répondre aux requêtes entrantes.
• Disable la laisse inactive jusqu’à son activation manuelle via l’état Active.

Pour un service Remote Access en production, Respond only constitue généralement le point de départ le plus compréhensible. Vérifier explicitement ce choix après un redémarrage du firewall ou du service afin de ne pas confondre activation et état de connexion.

Authentification et clé prépartagée

Les valeurs disponibles sous Authentication type sont Preshared key et Digital certificate. Digital certificate authentifie les extrémités par l’échange de certificats signés localement ou émis par une autorité de certification. Les certificats évitent un PSK partagé, mais nécessitent une chaîne de confiance entièrement planifiée et une prise en charge adaptée par le client. Un PSK doit être long, aléatoire, transmis séparément et renouvelé régulièrement de manière contrôlée.

Sophos utilise le dernier PSK configuré pour toutes les connexions ayant la même interface d’écoute et le même peer distant. Pour Remote Access, Remote host est généralement défini sur *. Une nouvelle stratégie générique ou une stratégie modifiée peut donc remplacer le PSK de configurations Remote Access existantes. Avant l’enregistrement, examiner toutes les stratégies qui utilisent le même port WAN et la même passerelle générique.

Avec un PSK, définir des valeurs correspondantes pour Local ID et Remote ID. Le type d’ID DER ASN1DN (X.509) n’est pas accepté avec un PSK. Les ID doivent correspondre au client natif et ne doivent pas être définis arbitrairement pour des raisons de commodité.

Port WAN, peer et sélecteurs

Sous Local WAN port, sélectionner le port WAN réellement accessible. Pour les clients dont l’adresse change, attribuer à Remote host la valeur générique *. Activer Allow NAT traversal lorsque les clients se trouvent derrière NAT, ce qui est habituel sur les réseaux domestiques, mobiles et d’hôtels.

Pour le parcours Remote Access typique, l’exemple Sophos utilise Remote subnet: Any, Local port: 1701 et Remote port: *. 1701 est le port L2TP du firewall ; le port client peut varier. Ces valeurs sont des sélecteurs de tunnel et ne remplacent pas une règle de firewall. L’accès ultérieur reste limité à des zones, destinations et services précis.

Remote host peut également contenir une adresse IP ou un nom d’hôte pour un correspondant fixe. Remote subnet décrit les réseaux distants ; vérifier cette valeur en fonction de la conception réelle du client. L’aide des champs autorise des ports TCP/UDP ou la valeur générique * pour Local port et Remote port ; l’exemple utilisant le port local 1701 n’est pas une prescription générale pour toutes les configurations de sélecteurs. L’aide de la stratégie intitule cette section QuickHA mode, tandis que le guide de configuration parle de sélecteurs Quick Mode. Il ne faut pas déduire de ce titre une fonctionnalité HA : les deux champs de port et les sélecteurs IPsec correspondants sont déterminants.

Avec Disconnect when tunnel is idle, le firewall peut déconnecter les clients inactifs après la période définie sous Idle session time interval. Adapter la valeur au mode de travail réel et la tester avec des pauses réalistes. Une durée trop courte entraîne des reconnexions inutiles ; sans limite, des sessions oubliées peuvent rester établies plus longtemps. Idle session time interval est exprimé en secondes.

Après Save, activer la stratégie au moyen de l’icône rouge dans la colonne Active. Le vert sous Active ne signifie pas encore qu’un client est connecté. L’état Connection distinct indique si le tunnel est effectivement établi ; l’aide décrit l’action de connexion accessible via son icône d’état. Pour un client distant, sa tentative de connexion depuis un réseau externe reste déterminante. Logs sur la page L2TP ouvre les journaux L2TP. Lorsque Active est désactivé, la stratégie est inactive, quel que soit l’état antérieur du tunnel.

Avec plusieurs sous-réseaux locaux et distants, un tunnel est créé pour chaque paire local/distant. L’état Connection peut être partiel : la configuration est active, mais au moins un tunnel n’est pas établi. Testez chaque paire requise et son flux de données séparément ; Active activé ne confirme pas tous les tunnels.

Accessibilité, routage et règle de firewall

Autoriser IPsec sur le WAN

Sous Administration > Device access, IPsec doit être autorisé pour l’accessibilité WAN requise. Cette autorisation est mise en œuvre aussi étroitement que la topologie le permet. Un PSK robuste ou un certificat ne justifie pas un accès inutilement large à WebAdmin, User Portal ou SSH. Device Access et Local Service ACL explique la séparation entre accessibilité du service et autorisation de l’utilisateur.

Définir Route Precedence de manière contrôlée

L’ordre par défaut documenté par Sophos est Static, SD-WAN Policy Routes, puis VPN. Pour L2TP, les routes VPN doivent au contraire être évaluées en premier ; Static et SD-WAN peuvent ensuite apparaître dans n’importe quel ordre. Se connecter à la CLI du firewall et sélectionner 4. Device Console. Y enregistrer d’abord l’état initial réel :

system route_precedence show

Définir ensuite l’ordre documenté pour L2TP et le vérifier à nouveau :

system route_precedence set vpn static sdwan_policyroute
system route_precedence show

Cette modification est globale et ne constitue pas un commutateur isolé pour la nouvelle stratégie L2TP. Avant et après, tester les chemins Static, SD-WAN et VPN qui se chevauchent ainsi que l’accès d’administration. Adapter Route Precedence sur Sophos Firewall explique l’effet et le rollback sécurisé.

Autoriser l’accès aux destinations internes

Sous Rules and policies > Firewall rules > IPv4 > Add firewall rule > New firewall rule, créer une règle journalisée, puis l’enregistrer avec Save. Attribuer un Rule name explicite, par exemple VPN-LAN. L’exemple Sophos utilisant Any pour la source, la destination et le service est simple pour un premier contrôle fonctionnel, mais ne constitue pas un bon standard de sécurité permanent. L’exemple présenté ici est plus restrictif :

• Source zone : VPN
• Source network : la plage L2TP 10.250.30.0/24 ou un objet IP host correspondant
• Destination zone : la zone contenant le réseau d’applications
• Destination network : 10.10.10.0/24 ou, de préférence, les serveurs nécessaires
• Services : HTTPS ou uniquement les services réellement requis
• Log firewall traffic : activé

Le trafic internet passant par le firewall nécessite une règle distincte de VPN vers WAN ainsi qu’une conception NAT et sécurité explicite. Cet accès n’est pas créé automatiquement du seul fait que le tunnel L2TP est établi.

Valider la connexion

La validation s’effectue depuis un véritable réseau externe. Un test depuis le même LAN ou via un chemin VPN déjà existant peut masquer des problèmes de routage, de NAT et d’accessibilité publique.

1. Se connecter avec un utilisateur pilote autorisé et la configuration client documentée.
2. Sous Remote access VPN > L2TP, contrôler séparément les états Active et Connection. Avec plusieurs sous-réseaux locaux et distants, un tunnel est créé pour chaque paire local/distant. L’état Connection peut être partiel : la configuration est active, mais au moins un tunnel n’est pas établi. Testez chaque paire requise et son flux de données séparément ; Active activé ne confirme pas tous les tunnels.
3. Vérifier que le client reçoit une adresse comprise entre 10.250.30.10 et 10.250.30.100 ainsi que les serveurs DNS prévus.
4. Résoudre un nom interne et atteindre via HTTPS une destination explicitement autorisée.
5. Dans Log Viewer, vérifier la Firewall Rule ID attendue, l’IP source de la plage L2TP, la destination, le service et l’action.
6. Vérifier le chemin retour du réseau de destination vers la plage L2TP et répéter le même accès après une reconnexion.
7. Réaliser un test négatif avec un utilisateur qui n’a pas été ajouté ; il ne doit pas obtenir de tunnel utilisable.
8. Tester le comportement idle, la déconnexion, la reconnexion et, en HA, un failover contrôlé avec une nouvelle connexion.

Une authentification réussie ne prouve pas le chemin de données. De même, un tunnel vert ne prouve pas que DNS, la règle, NAT et le chemin retour sont corrects. Tester les règles Sophos Firewall explique comment distinguer les preuves de Log Viewer et Packet Capture.

Dépanner méthodiquement

La stratégie est active, mais le tunnel reste down

Comparer d’abord le port WAN, l’accessibilité publique, IPsec sous Device Access, NAT Traversal, l’adresse client, le PSK ou le certificat, Local/Remote ID et le profil IPsec. Vérifier ensuite si une stratégie générique enregistrée plus récemment a remplacé le PSK attendu.

Pour une première séparation, utiliser l2tpd.log pour L2TP et strongswan.log ou charon.log pour la négociation IPsec. Services et fichiers journaux de Sophos Firewall fournit la correspondance complète. Corréler les journaux avec l’heure exacte, l’utilisateur, l’IP publique du client et le nom de la stratégie ; un redémarrage de service n’est pas la première étape de diagnostic.

La connexion échoue ou l’utilisateur n’obtient aucun accès

Sous Authentication > Services, vérifier la méthode pour VPN (IPsec/dial-in/L2TP/PPTP) authentication methods. Contrôler ensuite si l’utilisateur ou le groupe figure sous Add members et quel groupe apparaît comme groupe principal dans l’objet utilisateur. Avec RADIUS, vérifier séparément l’authentification et l’attribution facultative du lease.

Le tunnel est up, mais les destinations internes sont inaccessibles

Contrôler dans cet ordre l’adresse attribuée, Route Precedence, Firewall Rule ID, la route vers la destination et le chemin retour. Une route SD-WAN large ou une Static Route concurrente peut modifier le chemin. La plage L2TP doit être accessible depuis le réseau interne sans qu’une seconde route identique ou un réseau qui se chevauche ne prenne en charge le retour.

Si Log Viewer affiche Rule 0, une Rule ID inattendue ou aucune entrée correspondante, identifier la règle réellement utilisée avant d’élargir quoi que ce soit à Any. Si le paquet aller est visible mais qu’aucune réponse ne revient, poursuivre sur l’hôte de destination, sa passerelle, son firewall local ou sa route retour.

La connexion est lente ou instable

Contrôler la latence, la perte de paquets, la MTU ou la fragmentation, les changements de WAN et l’utilisation du CPU pendant un test reproductible. Un unique transfert SMB n’est pas un test propre du débit VPN. Plusieurs flux TCP contrôlés dans les deux sens aident à distinguer le tunnel, le transport et l’application.

Si seules les connexions L2TP sont instables, comparer les horodatages de l2tpd.log, des journaux IPsec, des événements WAN et du journal client. Modifier le profil, la MTU ou l’idle time séparément et dans une fenêtre de maintenance uniquement après avoir établi une relation concrète.

Ne pas transposer les règles L2TP lors du passage à Sophos Connect

La FAQ sur l’accès distant traite d’IPsec et de SSL VPN, et non d’une prise en charge supplémentaire des clients L2TP. Son tableau des plateformes indique pour Windows .pro ou .scx pour IPsec, ainsi que .pro ou .ovpn pour SSL VPN ; il indique les mêmes types de fichiers pour macOS avec Sophos Connect à partir de la version 2.1. macOS avec Connect 2.0 utilise respectivement .scx et .ovpn ; avant la version 2.0, IPsec utilise toujours Sophos Connect avec .scx, tandis que SSL VPN utilise un client tiers avec .ovpn. Android utilise des clients tiers avec .tgb pour IPsec ou .ovpn pour SSL VPN ; pour IPsec, iOS ne nécessite aucun client supplémentaire et télécharge la configuration depuis le VPN portal, tandis que SSL VPN nécessite un client tiers avec .ovpn. Vérifier la combinaison actuelle exacte du client et du système d’exploitation avant le remplacement. Vérifier le chiffrement sous Remote access VPN > IPsec > IPsec profiles > Encryption algorithm pour IPsec et sous Remote access VPN > SSL VPN > SSL VPN global settings > Cryptographic settings pour SSL VPN. L’affirmation générale de la FAQ concernant le chiffrement des connexions d’accès distant ne doit pas être appliquée à PPTP sans protection propre au protocole.

Avec le provisioning Sophos Connect, les passerelles dans .pro servent uniquement à récupérer les configurations depuis le portail, et non à choisir le tunnel : IPsec utilise l’interface configurée, tandis que SSL VPN utilise les interfaces de .ovpn présentes sous Network > Interfaces et autorisées par la Local Service ACL. Override hostname définit l’adresse publique SSL VPN souhaitée ; derrière un routeur, renseigner son FQDN public ou son IP WAN dans .pro, configurer une redirection DNAT appropriée sur le routeur et, pour IPsec, utiliser son IP WAN comme passerelle dans .scx. Le certificat privé par défaut de WebAdmin et du VPN Portal peut provoquer une erreur de confiance lors du provisioning ; corriger la chaîne de certificats au lieu de désactiver la vérification. La configuration du firewall pour Sophos Connect et la procédure SSL VPN remplacent ici la configuration L2TP.

Pour les modifications IPsec, la FAQ exige Edit connection > Update policy et une nouvelle récupération depuis le portail ; pour SSL VPN, les mises à jour manuelles concernent notamment le port, le protocole, la passerelle et le certificat du serveur SSL. .pro récupère automatiquement certaines modifications SSL VPN ; un nouvel import peut récupérer à nouveau les deux configurations. Pour distinguer une mise à jour de profil d’une erreur de téléchargement, suivre Télécharger à nouveau le profil SSL VPN. Sophos Connect utilise les passerelles SSL VPN de .ovpn dans l’ordre de priorité inverse, et pas nécessairement dans l’ordre de .pro. SSL VPN répartit la plage d’adresses entre des instances dont le nombre dépend du CPU, avec leurs propres sous-réseaux tun0 : les plages plus petites qu’un /24 réduisent la capacité d’attribution ; avec un /27 et huit instances, la FAQ indique qu’il ne reste qu’une adresse attribuable. Il ne s’agit pas d’une limite de plage L2TP. L’absence de téléchargements .ovpn peut également être liée à des ID utilisateur dépassant la limite commune des ID utilisateur et groupe de 65535 ; Vérifier la limite des ID utilisateur en toute sécurité décrit un nettoyage contrôlé plutôt qu’une suppression systématique.

Planifier la MFA pour la solution de remplacement sous Authentication > Multi-factor authentication, avec les options nécessaires User portal, SSL VPN remote access et IPsec remote access. Pour IPsec, le champ OTP séparé nécessite Prompt users for 2FA token et Apply, ou, dans le provisioning, otp: true et 2fa: 1. Sophos Connect transmet le mot de passe et l’OTP combinés sous la forme passwordotp et, selon la FAQ, ne prend pas en charge un processus de challenge OTP ; les méthodes par appel ou notification push sont prises en charge, et WebAdmin prend également en charge la MFA par challenge. Vérifier cette différence lors du pilote de provisioning, sans la transposer à un client L2TP natif. La FAQ limite également l’accès distant IPsec à une seule interface WAN ; cela n’implique ni la même limite pour L2TP ni une garantie de fonctionnement multi-WAN pour la solution de remplacement.

Migrer vers SFOS 22

Planifier la migration du firmware séparément d’une modification de la configuration L2TP. Avant la mise à niveau, inventorier le firmware et la plateforme exacts, les paramètres L2TP globaux, les utilisateurs et groupes principaux autorisés, chaque stratégie L2TP avec son profil, ses ID et son authentification, Device Access, Route Precedence ainsi que les règles de firewall et NAT associées. Préparer également une sauvegarde chiffrée et un accès d’administration indépendant. Utiliser le contrôle de mise à niveau SFOS 22 pour comparer le build source concret au tableau de mise à niveau actuel ; l’affirmation générale selon laquelle les configurations peuvent migrer vers 22.0 GA ne remplace pas ce contrôle du chemin.

Ne pas confondre L2TP avec Remote Access IPsec (legacy) : L2TP reste disponible dans SFOS 22.0 MR2, tandis que l’ancienne variante IPsec a été retirée dans 22.0 MR1. Un firewall contenant cette ancienne configuration ne peut pas être mis à niveau vers 22.0 MR1 ou une version ultérieure. En outre, SFOS 22.0 GA et les versions ultérieures ne prennent pas en charge les appliances matérielles XG ou SG. La plateforme et les types d’accès distant existants sont donc de véritables conditions de blocage, et pas de simples éléments d’inventaire.

SFOS 22.0 MR1 Build 490 a corrigé NC-162171, qui empêchait l’insertion de NAS-Identifier pour les connexions L2TP utilisant MS-CHAPv2 ou MS-CHAP. Si des règles RADIUS dépendent de NAS-Identifier et que le firewall vient d’un build antérieur, vérifier après la mise à niveau non seulement la connexion, mais aussi la requête RADIUS reçue et la stratégie RADIUS réellement appliquée. Cette correction ne prouve pas la compatibilité automatique de toutes les combinaisons de client et d’authentification.

Après le redémarrage, comparer la version du firmware et tous les champs inventoriés. Procéder ensuite à la validation complète depuis un réseau externe, y compris le test négatif, DNS, le chemin de données, le comportement idle et une nouvelle connexion après un failover HA. Conserver l’ancienne méthode d’accès comme repli contrôlé jusqu’à la réussite de ces contrôles.

Le rollback du firmware ne se limite pas à désactiver L2TP. Le firmware actif et le précédent résident dans des partitions séparées avec leurs états de configuration respectifs. Démarrer le firmware précédent réactive donc aussi son ancien état de configuration ; les modifications effectuées depuis la mise à niveau ne font pas partie de la configuration active après le rollback. Avant cette opération, sauvegarder séparément les modifications ultérieures nécessaires, vérifier la version cible prise en charge et confirmer la fenêtre de maintenance liée au redémarrage.

Effectuer un rollback sécurisé de la configuration L2TP

Le rollback consiste à rétablir uniquement les états modifiés au cours de cette procédure conformément à l’état initial documenté, et non à démanteler un environnement L2TP existant. Avant la première modification, relever donc les valeurs L2TP globales, y compris Enable L2TP, l’état Active de chaque stratégie concernée, la liste complète sous Add members, les autorisations des utilisateurs, les règles de firewall et l’autorisation IPsec sous Administration > Device access ; consigner séparément les nouveaux éléments et les modifications des éléments existants. Si des valeurs initiales manquent ou si aucune méthode de restauration exacte n’est confirmée pour le build installé, ne pas effectuer la modification concernée ; clarifier d’abord ce point avec Sophos Support. Une valeur par défaut documentée ne remplace pas une valeur initiale relevée.

Conserver l’accès d’administration indépendant ouvert pendant le rollback. Commencer par rétablir exactement l’ordre de Route Precedence enregistré auparavant, uniquement si cet ordre a été modifié au cours de cette procédure, puis le relire avec system route_precedence show et vérifier les chemins d’administration, Static, SD-WAN et VPN. Si l’ordre n’a pas été modifié, le conserver.

Dans une configuration existante, restaurer exactement et uniquement les valeurs, états des stratégies, appartenances et autorisations qui ont été modifiés. Conserver les stratégies, membres, règles et autorisations préexistants dans leur état initial ; si Enable L2TP était déjà activé, le laisser activé. L’annulation d’une modification individuelle effectuée dans Device Console ne justifie ni la suppression de ces accès ni la désactivation globale de L2TP.

Le retrait d’un déploiement créé exclusivement au cours de cette procédure constitue une opération distincte : avant toute désactivation ou suppression, vérifier les dépendances et confirmer qu’aucun accès de production toujours nécessaire n’est affecté. Désactiver uniquement alors la nouvelle stratégie L2TP et contrôler les effets avec un client pilote. Retirer ensuite exclusivement les règles de firewall et les autorisations IPsec nouvellement créées qui ne sont plus nécessaires, et supprimer de Add members uniquement les membres ajoutés au cours de cette procédure. Ne désactiver Enable L2TP que si cette option était désactivée avant la procédure et qu’aucune dépendance toujours nécessaire ne subsiste. Ne pas supprimer les éléments partagés existants dans le cadre du nettoyage.

Après le rollback, comparer les valeurs globales enregistrées, Show members, l’état des stratégies, les autorisations des utilisateurs, les règles et Device Access avec l’état initial documenté. Avec un client pilote externe, confirmer que les accès de production auparavant nécessaires fonctionnent toujours et que les autorisations de test retirées ne permettent plus aucun accès. Ne pas rétablir aveuglément la clé prépartagée à une ancienne valeur ; examiner ensemble toutes les stratégies utilisant le même port WAN et la même passerelle générique.

FAQ