Configurer l'accès à distance SSL VPN Sophos Firewall

Le SSL VPN reste un chemin d’accès à distance important, en particulier lorsque les utilisateurs travaillent depuis des hôtels, des WLAN invités, des réseaux cellulaires ou des réseaux tiers restrictifs. Mais ce n’est pas seulement la question de savoir si le tunnel sera construit ou non. Ce qui est crucial est de savoir si le pare-feu limite correctement l’accès, si DNS fonctionne, si MFA fonctionne et si les règles du pare-feu autorisent le trafic depuis la zone VPN de manière contrôlée.

L’article décrit la configuration côté pare-feu de l’accès à distance SSL VPN sur Sophos Firewall. Pour l’installation du client, Configurer Sophos SSL VPN avec Sophos Connect sous Windows, Configurer Sophos SSL VPN avec Sophos Connect sur macOS, Configurer Sophos SSL VPN sur iPhone et iPad et Configurer Sophos SSL VPN sur Android.

Pour la décision de base entre IPsec, SSL VPN, les clients mobiles et ZTNA, Sophos Connect ou SSL VPN : quelle solution d’accès à distance convient ? est le premier choix.

Quel article SSL-VPN convient ?

SSL VPN comprend la configuration du pare-feu, le portail, le client, l’authentification et l’analyse ultérieure des erreurs. Selon la tâche, une approche différente est appropriée :

• Configurer SSL VPN sur le pare-feu: Cet article
• Comparez essentiellement Sophos Connect ou SSL VPN: Sophos Connect ou SSL VPN : quelle solution d’accès à distance est la bonne ?
• Maintenir les versions et les profils des clients Sophos Connect: Vérifiez la version de Sophos Connect Client et mettez-la à jour en toute sécurité
• Configurer le client SSL-VPN sous Windows: Configurer Sophos SSL VPN avec Sophos Connect sous Windows
• Configurer le SSL VPN sur macOS, iOS ou Android: macOS, iPhone/iPad ou Android
• Utilisez Microsoft Entra ID SSO ou Entra-MFA: Configurer l’authentification unique Microsoft Entra ID pour Sophos Connect et VPN Portal
• VPN est connecté mais le trafic ne fonctionne pas: Tester la règle de pare-feu avec Log Viewer, Policy Test et Packet Capture
• Les transferts volumineux se bloquent ou certaines applications ne chargent pas : Vérifier MTU et MSS sur Sophos Firewall en cas de problèmes VPN.

Cette séparation est importante : un problème utilisateur dans le VPN Portal, un profil .ovpn obsolète, une règle de pare-feu manquante et un problème DNS se ressemblent souvent pour l’utilisateur. Pour l’analyse, ces niveaux doivent être séparés.

Image cible

Une structure SSL-VPN propre se compose de plusieurs éléments de base :

1. Les utilisateurs ou groupes sont autorisés dans la stratégie SSL VPN correcte.
2. Les paramètres globaux SSL VPN définissent la gateway, le port, le certificat, la plage de lease, le DNS et la cryptographie.
3. Le VPN Portal n’est accessible que dans la mesure nécessaire et est protégé par le MFA.
4. Les règles de pare-feu autorisent le trafic depuis la zone VPN uniquement vers les destinations requises.
5. Split Tunnel ou Full Tunnel est délibérément décidé.
6. Les clients importent un profil .ovpn actuel.
7. Les journaux, Packet Capture et les données d’assistance peuvent être évalués en cas d’erreur.

De nombreux problèmes SSL VPN surviennent car seul le téléchargement du client est documenté. En pratique, il faut considérer ensemble le portail, l’authentification, la policy SSL VPN, la règle firewall, le DNS et le NAT.

⚠️ SSL VPN est un point d’entrée accessible au public. MFA et les mots de passe forts sont importants, mais ne remplacent pas les limites sur Device access, les groupes d’utilisateurs restreints, les profils actuels, la journalisation et les révisions régulières.

⚠️ Les modifications apportées à la gateway, au port, au certificat, au DNS, à la plage de lease ou à la policy n’apparaissent pas automatiquement dans les profils clients déjà importés. Après les modifications pertinentes, le fichier .ovpn doit être retéléchargé, distribué et remplacé sur les clients.

Exigences

Avant la configuration, ces points doivent être clarifiés :

• Sophos Firewall avec la version actuelle SFOS.
• Accessibilité publique du pare-feu ou redirection de port en amont.
• FQDN ou adresse IP publique pour l’accès VPN.
• Certificat pour VPN Portal et SSL VPN, correspondant idéalement au FQDN.
• Utilisateurs ou groupes pour accès à distance.
• Serveur d’authentification pour VPN Portal et SSL VPN : local, Active Directory, RADIUS ou Microsoft Entra ID.
• Concept MFA/OTP pour VPN Portal et accès à distance.
• Réseaux cibles internes, serveurs DNS et domaine de recherche.
• Optez pour Split Tunnel ou Full Tunnel.
• Règles de pare-feu pour le trafic provenant de la zone VPN.
• Processus de mise à jour client et de redistribution du fichier .ovpn.

Si Microsoft Entra ID SSO doit être utilisé, l’authentification doit être préparée correctement avant de télécharger la configuration VPN. Le processus se trouve dans Configuration de l’authentification unique Microsoft Entra ID pour Sophos Connect et VPN Portal.

1. Préparer les objets locaux

Premièrement, les réseaux cibles doivent exister en tant qu’hôtes ou objets réseau :

Hosts and services > IP host

Objets typiques :

• LAN_Server: 10.10.10.0/24. serveurs internes
• LAN_Client: 10.10.20.0/24. Réseau client, si nécessaire
• DNS_Internal: 10.10.10.10. DNS interne ou contrôleur de domaine
• SSLVPN_Users: Groupe d’utilisateurs. Membres politiques

Vous ne devez pas simplement libérer des zones entières du réseau interne si seuls des serveurs ou des sous-réseaux individuels sont nécessaires. Plus les objets sont définis de manière précise, plus la règle de pare-feu sera simple par la suite.

Si des serveurs DNS sont utilisés dans le tunnel, ils ne doivent pas seulement être configurés dans les paramètres globaux SSL VPN, mais aussi exister comme objets cibles. Surtout avec Full Tunnel ou des ressources strictement limitées, le tunnel peut sinon être connecté alors que la résolution de noms reste cassée.

2. Vérifiez les paramètres globaux SSL-VPN

Les paramètres globaux s’appliquent à toutes les stratégies SSL d’accès à distance VPN :

Remote access VPN > SSL VPN > SSL VPN global settings

Protocole et port

Le SSL VPN peut utiliser TCP ou UDP selon la configuration. UDP est souvent plus efficace, TCP peut mieux fonctionner dans des réseaux restrictifs. La décision devrait être testée sur les réseaux à partir desquels les utilisateurs travaillent réellement.

En matière de ports, il faut éviter les chevauchements :

• SSL VPN Le port par défaut est souvent 8443.
• VPN Portal utilise 443 par défaut dans les versions actuelles de SFOS.
• Les règles WAF et SSL VPN ne peuvent pas se chevaucher sur la même IP WAN avec le même port et le même protocole.
• Si SSL VPN et VPN Portal utilisent le même port, les fonctions de sécurité de connexion ne peuvent pas fonctionner comme prévu.

Si WAF, VPN Portal, User Portal et SSL VPN fonctionnent sur la même IP WAN, vous devez consciemment documenter le port, le protocole et le certificat. Pour les bases de WAF, Sophos Firewall Configurer WAF et éviter les erreurs typiques convient.

Certificat et remplacement du nom d’hôte

Un certificat correspondant au nom de domaine complet public doit être utilisé sous Certificat de serveur SSL. Une erreur de certificat dans le profil VPN Portal ou SSL VPN entraînera ultérieurement des cas de support inutiles. Sous Override hostname, vous spécifiez le nom d’hôte ou l’adresse IP que les clients utilisent dans le profil .ovpn. Ceci est particulièrement important pour :

• plusieurs adresses IP WAN,
• routeur amont,
• NAT ou redirection de port devant le pare-feu,
• WAN-IP dynamique avec DDNS,
• des FQDN distincts pour WebAdmin, VPN Portal et SSL VPN.

Si le champ est laissé vide, plusieurs adresses d’interface peuvent se retrouver dans le profil. Cela peut fonctionner, mais dans les environnements de production, c’est souvent moins clair qu’un FQDN propre. Sophos Connect n’essaie pas simplement les gateways du fichier .ovpn dans l’ordre visible ; les gateways DNS dynamiques et l’ordre de plusieurs entrées peuvent donc agir différemment en pratique. Pour les setups productifs, un Override Hostname unique est plus simple à tester et à supporter.

Après avoir modifié le nom d’hôte de remplacement, vous devez télécharger un nouveau profil et vérifier si le client possède réellement le nouveau FQDN ou la nouvelle adresse IP publique. Sinon, vous risquez de devoir tester l’ancienne connexion même si la configuration du pare-feu est déjà correcte.

Plage de lease

Sophos Firewall attribue des adresses clients SSL VPN à partir de la plage de lease configurée. Cette plage ne doit pas entrer en collision avec les réseaux internes, les routes statiques, les VPN Site-to-Site, d’autres pools Remote Access ou des réseaux domestiques typiques.

Vous devez éviter les sous-réseaux particulièrement courants tels que :

• 192.168.0.0/24
• 192.168.1.0/24
• 192.168.2.0/24
• 10.0.0.0/24
• 10.0.1.0/24

Lorsque la plage de lease entre en collision avec le réseau domestique d’un utilisateur, le tunnel se connecte parfois avec succès, mais les destinations internes restent inaccessibles. Cela ressemble alors à un problème de règle firewall, mais il s’agit d’un problème de routing sur l’endpoint.

Pour IPv4, Sophos Firewall n’accepte dans les paramètres globaux SSL VPN que des sous-réseaux jusqu’à /24. Des réseaux plus petits comme /25 n’y sont pas sélectionnables. Même si peu d’utilisateurs sont attendus, il faut planifier un réseau VPN propre et non conflictuel et limiter l’accès par des règles firewall, pas par une plage de lease artificiellement petite.

Pour les règles firewall, utiliser les hôtes système ##ALL_SSLVPN_RW et, pour IPv6, ##ALL_SSLVPN_RW6, et non des objets recréés manuellement avec d’anciennes plages de lease.

Adresses IP SSL VPN statiques et durée de vie de la clé

Les adresses IP SSL statiques VPN peuvent être utiles dans des cas individuels, par exemple pour un accès administrateur, un accès spécial strictement enregistré ou des applications héritées avec approbation basée sur IP. Cependant, ils ne conviennent pas comme norme à tous les utilisateurs. Plus les affectations sont statiques, plus l’exploitation, l’analyse des erreurs et les migrations ultérieures deviennent difficiles.

De plus, Sophos Firewall ne prend pas en charge les connexions Remote Access simultanées pour les utilisateurs avec une adresse IP SSL VPN statique. C’est important pour les comptes partagés, les appareils parallèles ou les tests dans lesquels un utilisateur doit être connecté sur un ordinateur portable et un deuxième appareil en même temps. De tels designs ne doivent pas être résolus avec des IP statiques.

Un cas particulier spécifique est documenté dans la liste des problèmes connus : pour SSL VPN avec une authentification locale et une adresse IP SSL VPN attribuée de manière statique, la réauthentification peut échouer une fois la durée de vie de la clé expirée. Le pare-feu peut traiter l’adresse de bail déjà attribuée comme un conflit. Les utilisateurs doivent alors se reconnecter manuellement même si le tunnel fonctionnait auparavant. Une valeur de durée de vie de clé typique est 18000 secondes.

Si un utilisateur doit se connecter à plusieurs reprises après plusieurs heures, vous ne devez pas seulement vérifier MFA, la version du client et la règle de pare-feu. De plus, ces points appartiennent à l’analyse :

• L’authentification locale est-elle utilisée pour SSL VPN ?
• L’utilisateur dispose-t-il d’une adresse IP SSL VPN statique ?
• Le problème survient-il approximativement après l’expiration de la durée de vie de la clé ?
• Le même utilisateur travaille-t-il de manière plus stable avec l’attribution dynamique d’IP ?
• Une adresse IP statique est-elle vraiment nécessaire ou une règle concernant le groupe d’utilisateurs, l’hôte du système SSL-VPN et la journalisation est-elle suffisante ?

Sophos cite deux contre-mesures pragmatiques : planifier la durée de vie des clés de manière à ce qu’elle couvre la journée de travail normale, ou utiliser l’allocation IP dynamique. Dans de nombreux environnements, l’allocation dynamique est plus propre car les règles de pare-feu doivent déjà être contrôlées dans la zone VPN, le groupe d’utilisateurs, les objets cibles et les hôtes système SSL VPN.

DNS et nom de domaine

Pour la résolution de noms interne, des serveurs DNS et éventuellement un nom de domaine sont définis dans les paramètres globaux SSL-VPN. Dans les environnements Active Directory, il s’agit généralement d’un serveur DNS interne ou d’un contrôleur de domaine.

De plus, le DNS de la zone VPN doit être autorisé sous Administration > Device access si le pare-feu lui-même est utilisé comme résolveur DNS dans la conception VPN.

Si DNS ne fonctionne pas dans le tunnel, vous devez tester séparément :

• La cible est-elle joignable via l’adresse IP ?
• Le serveur DNS interne est-il autorisé par la règle du pare-feu ?
• Le client reçoit-il le bon domaine de recherche ?
• Le client utilise-t-il réellement le profil .ovpn actuel ?
• La configuration DNS ou DoH locale du point final intervient-elle ?

Si un serveur DNS interne doit être joint directement, l’utilisateur VPN doit aussi avoir accès à ce serveur DNS. Cela signifie que le serveur DNS doit faire partie des ressources autorisées ou être permis via une règle firewall adaptée depuis la zone VPN. Avec Full Tunnel, DNS ne doit pas être traité comme un effet secondaire de la règle Internet, mais testé consciemment.

Pour Split Tunnel, le DNS doit être planifié avec une attention particulière. Si seuls les réseaux cibles internes sont acheminés via le tunnel, il doit être clair si les noms internes sont résolus via le serveur DNS interne et si les noms publics sont résolus localement ou via le pare-feu. Sinon, des erreurs surviennent dans lesquelles l’accès IP fonctionne, mais les noms d’hôtes internes ne sont résolus que sur des clients individuels.

3. Créer une stratégie SSL VPN

La politique est créée sous :

Remote access VPN > SSL VPN

Processus :

1. Sélectionnez Add.
2. Utilisez Configure manually.
3. Attribuez un nom, par exemple SSLVPN-Remote-Users.
4. Sélectionnez les utilisateurs ou groupes autorisés sous Membres de la stratégie.
5. Réglez Split Tunnel ou Full Tunnel.
6. Pour Split Tunnel, sélectionner les Permitted network resources ; pour Full Tunnel, préparer les futurs objets cibles surtout pour les règles firewall.
7. Configurez éventuellement Disconnect idle clients.
8. Enregistrez puis vérifiez auprès d’un utilisateur test.

Important : Si des utilisateurs ou des groupes sont inscrits dans une stratégie SSL-VPN plus récente et sont déjà inclus dans une ancienne stratégie SSL-VPN, Sophos Firewall supprime cette association de la stratégie précédente. Vous devez donc éviter les chevauchements de politiques et définir clairement quelle politique s’applique à chaque groupe d’utilisateurs.

Après les modifications de stratégie, un utilisateur normal du groupe cible doit être vérifié dans VPN Portal. C’est exactement la configuration SSL-VPN attendue qui doit être visible, pas plusieurs anciens profils ou aucune configuration du tout. Ce test de portail révèle les erreurs de groupe plus rapidement qu’un simple test d’administrateur avec des droits spéciaux.

Les Permitted network resources limitent avec Split Tunnel les objectifs internes que les utilisateurs distants doivent atteindre. Avec Use as default gateway, ce point est différent : Sophos Firewall n’impose pas les Permitted Resources comme limite d’accès. Tout le trafic passe par la firewall, et la limitation réelle doit se faire par règles firewall, zones, objets cibles, services et logging.

Pour Full Tunnel, il faut quand même modéliser proprement les réseaux cibles internes sous forme d’objets, mais ne pas croire que la policy SSL VPN seule les limite. Les interfaces ne sont pas un bon substitut, car une interface ne décrit pas automatiquement quels sous-réseaux sont fonctionnellement autorisés derrière elle.

Si des objets FQDN sont utilisés comme ressources autorisées avec Split Tunnel, l’exploitation doit être planifiée consciemment. Les logs SSL VPN montrent les adresses IP résolues, et les changements FQDN dynamiques ne sont pas automatiquement appliqués aux tunnels existants. Les utilisateurs concernés doivent se déconnecter et se reconnecter pour que les nouvelles adresses cibles prennent effet.

4. Choisissez Split Tunnel ou Full Tunnel

Split Tunnel

Avec Split Tunnel, seul le trafic vers les ressources internes autorisées passe par le tunnel VPN. Le trafic Internet de l’utilisateur se poursuit directement sur le réseau local de l’utilisateur.

Split Tunnel convient souvent :

• Accès à quelques applications internes,
• charge de pare-feu réduite,
• de meilleures performances utilisateur,
• des sites distants plus petits et des utilisateurs mobiles.

La sécurité dépend alors davantage du point final, de l’environnement réseau local et des ressources internes partagées.

Full Tunnel

Avec Full Tunnel, tout le trafic des utilisateurs distants est acheminé via le pare-feu. Dans Sophos Firewall, cela correspond à l’option Utiliser comme passerelle par défaut.

Full Tunnel est plus adapté si :

• Le trafic Internet doit être contrôlé de manière centralisée,
• La protection Web, DNS Protection ou la journalisation doivent s’appliquer aux utilisateurs VPN,
• Les utilisateurs travaillent à partir de réseaux non sécurisés,
• La conformité nécessite une évaluation centrale.

Pour Full Tunnel, la stratégie SSL VPN seule ne suffit pas. Vous avez également besoin de règles de pare-feu et de NAT/SNAT pour le trafic Internet provenant de la zone VPN. Vous devez également tester au préalable les performances, la bande passante, le filtrage Web et la journalisation. Full Tunnel ne doit pas être activé simplement parce que les cibles individuelles Split-Tunnel sont difficiles à maintenir. Lorsque tout le trafic Internet passe par le pare-feu, la capacité, le filtrage Web, le DNS, la journalisation, la protection des données et les frais de support font partie de la conception.

Même avec Full Tunnel, les réseaux cibles internes et les serveurs DNS doivent être modélisés proprement comme destinations firewall. Sinon, le chemin Default Gateway fonctionne peut-être, mais les applications internes ou la résolution de noms dépendent d’une règle Internet trop large.

5. Créez des règles de pare-feu pour la zone VPN

L’établissement d’un tunnel ne signifie pas que la circulation est autorisée. Pour accéder aux ressources internes, vous avez besoin d’une règle de pare-feu adaptée :

Rules and policies > Firewall rules

Règle recommandée pour Split Tunnel :

• Nom de la règle: VPN_SSLVPN_to_Internal_Servers
• Zone source: VPN
• Source networks and devices: ##ALL_SSLVPN_RW
• Destination zones: zones cibles internes, par exemple LAN ou DMZ
• Destination networks: uniquement les serveurs ou sous-réseaux autorisés
• Services: uniquement les services nécessaires
• Journaliser le trafic du pare-feu: activer

Pour Full Tunnel, vous avez également besoin d’une règle allant de VPN à WAN ou Any, selon la conception. Les réseaux sources doivent toujours être les hôtes du système SSL VPN. Il faut ensuite vérifier s’il existe une règle SNAT appropriée.

S’il existe une connexion mais qu’aucun accès ne fonctionne, vous devez d’abord vérifier le Log Viewer. Tester la règle de pare-feu avec Log Viewer, Policy Test et Packet Capture convient à la méthodologie.

Les règles pour SSL VPN doivent figurer dans un groupe clairement nommé, par exemple VPN Remote Access. Une règle générale telle que VPN_to_LAN_Any est pratique, mais rend l’analyse ultérieure des erreurs difficile et permet souvent un accès plus large que ce qui est techniquement nécessaire. Il est préférable de définir des règles distinctes par zone cible ou classe de service avec journalisation active.

6. Sécurisez les VPN Portal et Device Access

Les utilisateurs chargent généralement Sophos Connect et le fichier .ovpn à partir du VPN Portal :

Administration > Admin and user settings
Administration > Device access
Authentication > Services
Authentication > Multi-factor Authentication

Vérifiez au moins :

• Port et certificat VPN Portal.
• Méthodes d’authentification VPN Portal.
• Méthodes d’authentification SSL VPN.
• MFA pour VPN Portal et accès à distance.
• Device Access pour VPN Portal uniquement dans les zones requises.
• Device Access pour SSL VPN sur la zone WAN seulement si requis en externe.
• Pas de User Portal ouvert en permanence sur le WAN lorsqu’il n’est pas utilisé.

Pour renforcer les services de pare-feu locaux, Device Access et Local Service ACL conviennent à Sophos Firewall. Pour les bases de MFA, convient à MFA pour Sophos Firewall WebAdmin, VPN Portal et activer l’accès à distance.

Le VPN Portal ne semble utile aux utilisateurs que si eux-mêmes ou leurs groupes sont inclus dans une stratégie d’accès à distance appropriée. Si l’attribution de stratégie est manquante, l’utilisateur ne verra pas les téléchargements de configuration requis.

Sous Authentication > Services, VPN Portal et SSL VPN doivent être vérifiés séparément. Le VPN Portal contrôle l’authentification pour le téléchargement et l’accès au profil ; SSL VPN authentication methods contrôle l’authentification réelle du tunnel. Les deux zones peuvent utiliser le même serveur, mais ne sont pas automatiquement correctement alignées. Avec RADIUS, il faut en plus noter que le MFA challenge-based n’est pas pris en charge pour le VPN Portal ; ces designs doivent être testés avec un vrai utilisateur avant le rollout.

Si VPN Portal ou SSL VPN doivent être autorisés dans la zone WAN, cela doit être délibérément documenté. Dans de nombreux environnements, il ne suffit pas d’ouvrir le service dans le monde entier et de s’appuyer sur MFA. Dans la mesure du possible, les réseaux à source fixe, les restrictions nationales, les flux de menaces, la vérification des journaux ou une conception d’accès à distance en amont doivent être examinés.

Il est important de séparer WebAdmin et VPN Portal. WebAdmin est l’interface d’administration du pare-feu. Le VPN Portal est l’accès utilisateur pour les téléchargements et les profils VPN. Les deux services ne doivent pas être regroupés car ils présentent des risques, des ports, des autorisations et des audiences différents.

7. Distribuer le profil client

Après la configuration de la stratégie et du portail, le fichier .ovpn est distribué. Cela peut se produire via le VPN Portal ou contrôlé par le processus d’administration.

Important :

• Après modification de la gateway, du port, du certificat, du DNS, de la plage de lease, de la policy ou de l’authentification, le profil doit être rechargé.
• Une mise à jour de Sophos Connect ne remplace pas un ancien profil .ovpn.
• Les noms de profil doivent être uniques.
• Les anciens profils doivent être supprimés lors d’un changement d’emplacement, de passerelle ou d’utilisateur.
• Windows, macOS, iOS, Android et Linux utilisent parfois des chemins clients différents.
• Les fichiers de provisioning Sophos Connect (.pro) peuvent importer automatiquement des configurations IPsec et SSL VPN, mais ils relèvent d’un modèle d’exploitation Sophos Connect et ne remplacent pas une policy SSL VPN propre.

Pour Sophos Connect, il faut vérifier activement les limites de plateforme : les clients actuels prennent en charge Windows 10 et 11, macOS 13 ou plus récent, et Windows ARM à partir de Sophos Connect 2.5. Microsoft Entra ID SSO dans le client Sophos Connect est un scénario Windows avec Sophos Connect 2.4 ou plus récent. Les plateformes mobiles comme iOS et Android n’utilisent pas Sophos Connect pour SSL VPN, mais des apps compatibles OpenVPN ou d’autres chemins client.

Modifications typiques du profil en fonctionnement :

• Nouveau FQDN ou nouvelle IP publique: Téléchargez à nouveau .ovpn et remplacez l’ancien profil
• Port ou protocole modifié: Réimportez le profil et supprimez l’ancienne entrée de connexion
• Certificat renouvelé ou modifié: Redistribuer le profil et vérifier activement les avertissements du certificat
• Le serveur DNS ou le nom de domaine ont été modifiés: Importer un nouveau profil et tester la résolution du nom
• Plage de lease modifiée: réimporter le profil et vérifier la route ou l’adresse client
• Groupe d’utilisateurs ou stratégie modifiés: Testez le téléchargement du portail avec un utilisateur cible normal

Pour les mises à jour client et la maintenance des versions, Vérifiez la version du client Sophos Connect et mettez-la à jour en toute sécurité.

Avec Sophos Connect, un fichier de provisioning charge la configuration .ovpn uniquement pour les utilisateurs rattachés à une policy SSL VPN. Si un utilisateur reçoit via fichier .pro uniquement IPsec ou aucune connexion SSL VPN, le fichier de provisioning n’est donc pas automatiquement défectueux. Vérifier d’abord Policy members, accessibilité du VPN Portal, méthodes d’authentification et groupe utilisateur.

Test après configuration

Avec un utilisateur test, vous ne devez pas seulement vérifier si Sophos Connect affiche Connected.

Liste des tests :

• L’utilisateur voit le téléchargement de Sophos Connect et la configuration SSL VPN dans le VPN Portal.
• Le fichier .ovpn peut être importé.
• MFA est interrogé comme prévu.
• Le client reçoit une adresse de la plage de lease SSL VPN.
• L’itinéraire vers les réseaux internes autorisés apparaît au point final.
• Avec Full Tunnel, il est clair que les accès internes sont limités par les règles firewall, pas seulement par Permitted Resources.
• Pour les ressources FQDN, un test de reconnexion fonctionne après changement DNS.
• Les noms DNS internes sont résolus.
• L’accès aux serveurs autorisés fonctionne.
• Les réseaux non autorisés restent bloqués.
• Log Viewer affiche la règle de pare-feu correcte.
• Un test volontairement négatif sera rejeté et enregistré.
• Packet Capture affiche le trafic via une interface tun si nécessaire.
• L’accès Internet et SNAT fonctionnent également avec Full Tunnel.

Si le test n’est effectué qu’avec un seul utilisateur administrateur, il est facile de manquer des erreurs de groupe et de stratégie. Un utilisateur pilote normal du groupe cible est préférable.

Un bon test d’acceptation inclut toujours un accès bloqué. C’est le seul moyen de voir si les règles de pare-feu sont vraiment restrictives ou si une règle trop large située plus loin dans l’ensemble des règles autorise toujours l’accès.

Test d’acceptation par scénario

Avant un déploiement à grande échelle, au moins ces cas de test doivent être clairement documentés :

• Nouvel utilisateur: Inscription sur VPN Portal et importation de profil. L’utilisateur voit uniquement la configuration SSL-VPN correspondante et peut importer le profil
• MFA actif: Connectez-vous avec OTP correct et incorrect. Le facteur correct autorise l’accès, le facteur incorrect est rejeté et enregistré
• Split Tunnel: Accès aux cibles internes autorisées et non autorisées. Les destinations autorisées fonctionnent, les autres réseaux restent bloqués
• Full Tunnel: Accès Internet via VPN. Les règles de pare-feu, SNAT, DNS et la politique Web/sécurité fonctionnent comme prévu
• DNS: Accès par nom et par adresse IP. Les erreurs DNS peuvent être séparées des problèmes de routage ou de règles
• Changement de profil: Importer un nouveau profil .ovpn. Le FQDN, le port, le DNS ou le certificat modifié sont visibles dans le profil client
• Cas d’erreur: vérifier Log Viewer et Packet Capture. La règle firewall réellement matchée et le flux de paquets doivent être traçables.

Pour les environnements de production, chaque test doit contenir une heure, un utilisateur, une plateforme client et une cible concrète. Des déclarations comme « VPN fonctionne » ou « VPN ne fonctionne pas » sont trop imprécises pour les cas de support ultérieurs.

Collecter des journaux et des preuves

Si vous rencontrez des problèmes SSL-VPN, vous devez d’abord préciser si l’erreur concerne la connexion, la configuration du tunnel ou l’accès aux destinations internes. Cette séparation permet de gagner du temps car sinon l’authentification, le profil client, les règles de routage et de pare-feu sont vérifiés ensemble.

Pour un cas de test reproductible, ces informations sont à noter :

• Nom d’utilisateur et groupe: montre quelle stratégie et authentification SSL-VPN doivent s’appliquer
• Plateforme client et version Sophos Connect: sépare les erreurs client de la configuration du pare-feu
• Heure du test: rend les journaux d’authentification Log Viewer, sslvpn.log et d’authentification comparables
• Réseau source de l’utilisateur: aide avec les problèmes d’hôtel-WLAN, cellulaires, CGNAT, pare-feu restrictifs ou ports
• Système et service cible: empêche les déclarations trop larges telles que « VPN ne fonctionne pas »
• Résultat par adresse IP et par nom DNS: sépare les problèmes de routage et de DNS

Vous devez ensuite effectuer le test dans cet ordre :

1. Vérifiez l’authentification : Vérifiez dans Log Viewer et si nécessaire dans les journaux d’authentification si l’utilisateur, le MFA, le groupe et le serveur d’authentification ont réussi. Pour Microsoft Entra ID SSO, oauth_sso_vpn.log est également pertinent.
2. Vérifiez l’état du tunnel : Vérifiez la connexion SSL VPN, l’adresse du bail et l’état OpenVPN. sslvpn.log et openvpn-status*.log aident du côté du pare-feu.
3. Vérifiez la règle de pare-feu : Recherchez le trafic de la zone VPN dans la zone Log Viewer et vérifiez quelle règle correspond réellement. La règle doit avoir Enregistrer le trafic du pare-feu actif.
4. Vérifiez le flux de paquets : Si le Log Viewer ne suffit pas, filtrez la source, la destination et le service avec Packet Capture. Ce qui est important est de savoir si les packages sont uniquement Incoming ou deviennent également Forwarded.
5. Vérifiez la page de destination : Si le trafic quitte le pare-feu mais qu’aucune réponse ne revient, la route de retour, le pare-feu du serveur, le pare-feu de l’hôte local ou un conflit de réseau sont plus probables que la stratégie SSL VPN.

Dépannage Sophos Firewall : Services et journaux convient pour attribuer les fichiers journaux les plus importants. Pour l’analyse des règles avec Log Viewer, Policy Test et Packet Capture, Tester la règle de pare-feu avec Log Viewer, Policy Test et Packet Capture convient.

Dépannage

L’utilisateur ne voit pas la configuration SSL VPN dans VPN Portal

L’affectation de stratégie est généralement manquante. Vérifiez si l’utilisateur ou son groupe est inclus dans la stratégie SSL VPN sous Membres de la stratégie. De plus, l’authentification et l’accessibilité des portails MFA et VPN doivent être vérifiées.

Si la connexion et l’attribution de stratégie fonctionnent correctement, mais que le téléchargement du fichier .ovpn est toujours manquant ou échoue, la limite d’ID utilisateur Sophos Firewall doit également être vérifiée. Ceci est particulièrement pertinent si plusieurs utilisateurs utilisent le portail, mais que seuls les téléchargements individuels échouent de manière inattendue.

Le tunnel se connecte, mais les systèmes internes ne sont pas accessibles

Vérifiez d’abord si une route vers le réseau cible interne existe au point de terminaison. Recherchez ensuite dans le Log Viewer le trafic provenant de la zone VPN. Si aucun trafic n’est visible, le client n’atteint pas le pare-feu comme prévu ou le profil est obsolète.

Si le trafic est visible mais qu’une mauvaise règle s’applique, l’ordre des règles ou la définition du service/cible doit être corrigé. S’il n’y a aucune réponse, il est probable qu’il y ait un conflit de routage, de pare-feu de destination, de pare-feu de serveur local ou de réseau.

Après un changement, seuls certains clients fonctionnent

Si les nouveaux utilisateurs travaillent mais pas les anciens clients, la distribution des profils est généralement le problème. Vous vérifiez si les clients concernés ont réellement importé le profil .ovpn actuel et si les anciennes entrées de connexion ont été supprimées.

Surtout après des modifications du FQDN, du port, du certificat, du DNS, de la plage de lease, de la policy ou de l’authentification, il ne suffit pas d’enregistrer la firewall. Il faut tester activement un téléchargement de profil avec un utilisateur normal. Ensuite, on peut vérifier sur l’endpoint si la gateway, le DNS et les routes correspondent au design actuel.

Le DNS ne fonctionne pas

Vous vérifiez si l’accès via l’adresse IP fonctionne. Si tel est le cas, l’erreur vient probablement du DNS. Vérifiez ensuite le serveur DNS dans les paramètres SSL globaux VPN, le nom de domaine, Device Access pour le DNS de la zone VPN et le comportement DNS du point de terminaison.

Si le serveur DNS interne lui-même manque dans les ressources autorisées ou n’est accessible par aucune règle firewall depuis la zone VPN, un profil .ovpn correct ne suffit pas. DNS doit donc toujours être testé avec un serveur DNS concret, un nom interne concret et un filtre Log Viewer sur le service DNS.

L’accès ne fonctionne que pour certains utilisateurs

L’appartenance à un groupe, le mappage de stratégie, les adresses IP statiques SSL VPN, le statut MFA ou les profils obsolètes sont alors plus probables qu’une erreur globale de pare-feu. Vous devez également vérifier les affectations de stratégie en double.

Si un utilisateur utilise plusieurs appareils en parallèle ou si un compte commun est utilisé, vérifier particulièrement les adresses IP SSL VPN statiques. Sophos ne prend pas en charge les connexions Remote Access simultanées pour le même utilisateur avec adresse IP SSL VPN statique.

L’utilisateur doit se reconnecter après plusieurs heures

Si SSL VPN fonctionne initialement, mais qu’après plusieurs heures, une nouvelle connexion ou une reconstruction manuelle est nécessaire, vous devez d’abord vérifier le modèle d’heure, l’authentification et le modèle de bail. Ceci est particulièrement pertinent pour l’authentification locale avec une adresse IP SSL VPN attribuée de manière statique.

Processus pratique :

1. Notez l’heure à laquelle la connexion a été établie et interrompue.
2. Comparez l’heure avec la durée de vie de la clé configurée.
3. Vérifiez si l’utilisateur dispose d’une adresse IP SSL VPN statique.
4. Testez l’attribution IP dynamique pour un utilisateur pilote si cela est opérationnellement possible.
5. Vérifiez sslvpn.log, openvpn-status*.log et Log Viewer pour l’authentification, l’adresse de bail et la reconnexion.
6. Si une durée de vie de clé plus longue est choisie, documentez la modification et ne la considérez pas comme un remplacement du MFA ou un contrôle de session propre.

Si les adresses IP statiques ne sont utilisées que pour simplifier les règles de pare-feu, la conception doit être retravaillée. Dans la plupart des cas, les groupes, les cibles clairement nommées, les services restreints et la journalisation constituent une meilleure base que les adresses IP des utilisateurs individuels.

Full Tunnel n’a pas accès à Internet

Avec Utiliser comme passerelle par défaut, une règle de pare-feu est requise pour le trafic de la zone VPN vers Internet et une règle SNAT adaptée. De plus, les politiques Web, DNS et de sécurité doivent être planifiées de manière à ne pas bloquer de manière inattendue les utilisateurs de VPN.

La connexion est établie, mais les transferts importants sont suspendus

Si la connexion, le DNS et les petits accès fonctionnent, mais que RDP, les transferts de fichiers, les applications Web ou les téléchargements volumineux se bloquent, vous devez vérifier MTU et MSS. Le modèle d’erreur correspond souvent à une fragmentation, à un PPPoE, à des connexions tunnelisées ou à un chemin asymétrique, et pas seulement au SSL VPN lui-même.

Pour une analyse systématique, Sophos Firewall Vérifiez MTU et MSS pour les problèmes VPN convient.

WAF ou portail entre en collision avec SSL VPN

Si WAF, VPN Portal, User Portal et SSL VPN s’exécutent sur la même IP WAN, le port et le protocole doivent être clairement séparés. Les combinaisons partagées de WAN-IP, de port et de TCP sont particulièrement critiques. Si les gouttes ne sont pas claires, vérifiez Log Viewer et Packet Capture.

Le profil est obsolète après une modification

Après toute modification de la politique SSL-VPN, de la passerelle, du DNS, du certificat, du port ou de l’authentification, le fichier .ovpn doit être retéléchargé et importé. De nombreux problèmes apparents des clients sont dus à des profils obsolètes.

Si Sophos Connect est exploité avec un fichier de provisioning .pro, vérifier en plus si le client a réellement mis à jour le profil ou s’il utilise encore une ancienne entrée de connexion. Sur des appareils Windows partagés avec Entra ID SSO, il faut forcer une nouvelle connexion SSO après un changement d’utilisateur afin que le contexte de l’utilisateur précédent ne reste pas actif.

Liste de contrôle opérationnel

Avant le déploiement productif

• FQDN et certificat vérifiés pour VPN Portal et SSL VPN.
• La plage de lease SSL VPN n’entre pas en conflit avec les réseaux internes ou les réseaux domestiques typiques.
• La plage de lease IPv4 est planifiée comme /24 ou réseau plus grand sélectionnable, pas comme design /25 plus petit.
• La stratégie SSL-VPN contient les utilisateurs ou groupes appropriés.
• Split Tunnel ou Full Tunnel est délibérément décidé.
• Les ressources réseau autorisées sont étroitement définies dans Split Tunnel.
• Avec Full Tunnel, les règles firewall limitent les objectifs et services internes.
• Le serveur DNS et le nom de domaine sont correctement définis.
• Les serveurs DNS internes sont accessibles comme ressource autorisée ou via une règle adaptée.
• La règle de pare-feu de VPN vers les cibles internes existe et se connecte.
• Full Tunnel a des règles Internet et SNAT.
• Device Access pour SSL VPN et VPN Portal est délibérément défini.
• MFA est testé pour l’accès à distance.
• L’utilisateur test peut télécharger, importer un profil et atteindre ses objectifs internes.

Pour les opérations en cours

• MFA forcé pour VPN Portal et Remote Access.
• Vérifiez régulièrement les groupes VPN.
• Gardez les règles de pare-feu strictes pour VPN et enregistrez-vous.
• Vérifier la plage de lease avant les changements réseau.
• Utilisez uniquement des adresses IP SSL VPN statiques spécifiquement et vérifiez-les régulièrement.
• Documenter le DNS et le domaine de recherche.
• Renouveler les certificats du portail et SSL VPN avant l’expiration.
• Suivre les versions de Sophos Connect.
• Planifier la redistribution du profil après les modifications.
• Évaluer les logs sur le long terme à l’aide du Syslog ou du Sophos Central si la traçabilité est importante.

Dépannage Sophos Firewall : Services et journaux convient aux fichiers journaux et aux services.

Vérifiez régulièrement les cas particuliers

• Les adresses IP statiques SSL VPN sont justifiées et documentées.
• Les adresses IP statiques SSL VPN ne sont pas nécessaires pour des utilisateurs qui ont besoin de connexions Remote Access parallèles.
• Key Lifetime correspond au modèle opérationnel et a été testé avec Reconnect.
• L’ancien profil .ovpn est redistribué après modifications.
• Les ressources FQDN sont testées avec le comportement de reconnexion.
• VPN Portal, User Portal, WAF et SSL VPN n’entrent pas en collision sur la même IP WAN avec port et protocole.
• Les utilisateurs disposant de droits spéciaux ou d’un accès administrateur sont vérifiés séparément.

FAQ