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 : L’aide actuelle de SFOS 22 continue de documenter L2TP comme un type d’accès distant configurable. Sophos n’a publié aucun avis de retrait à son sujet. Cela ne garantit toutefois pas sa prise en charge dans une future version majeure. 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 de compatibilité ou de maintien d’un environnement existant.

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. PPTP n’est pas une solution de repli moderne : le protocole ne définit pas lui-même de chiffrement et ne devrait plus être planifié pour de nouveaux accès distants.

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.

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. Ne définir un DNS secondaire et WINS que lorsque l’environnement en a réellement besoin.

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.

Ajouter ensuite le groupe L2TP_Users via Add members et le contrôler 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 le groupe principal utilisé pour l’évaluation L2TP.

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. 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é 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.

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.

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.

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

Sophos exige que les routes VPN soient évaluées avant Static et SD-WAN Policy Routes pour L2TP. Enregistrer d’abord l’état initial dans Device Console :

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, créer une règle IPv4 journalisée. L’exemple Sophos utilisant Any pour la source, la destination et le service est simple pour un premier test 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.
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.

Effectuer un rollback sécurisé

Conserver l’accès d’administration indépendant ouvert pendant le rollback. Restaurer d’abord exactement la Route Precedence enregistrée et tester les chemins d’administration, Static, SD-WAN et VPN. Désactiver ensuite la stratégie L2TP et confirmer avec un client pilote qu’aucune dépendance de production ne subsiste.

Les règles de firewall et l’autorisation IPsec peuvent ensuite être supprimées si aucun autre service n’en dépend. Ce n’est qu’après cela que les utilisateurs sont retirés de Add members et que Enable L2TP est désactivé. La Preshared Key ne doit pas être rétablie aveuglément à une ancienne valeur ; toutes les stratégies utilisant le même port WAN et la même passerelle générique doivent être examinées ensemble.

FAQ