Configurer l'accès distant SSL VPN sur Sophos Firewall

Le SSL VPN reste un moyen important d’accès distant sur Sophos Firewall, surtout lorsque les utilisateurs travaillent depuis des hôtels, des réseaux Wi-Fi invités, des réseaux mobiles ou des réseaux étrangers restrictifs. Ce qui est crucial, ce n’est pas seulement si le tunnel est établi, mais aussi si le pare-feu limite correctement l’accès, si le DNS fonctionne, si le MFA est appliqué et si les règles de pare-feu contrôlent et autorisent le trafic depuis la zone VPN.

Cet article décrit la configuration côté pare-feu de l’accès distant SSL VPN sur Sophos Firewall. Pour l’installation du client, consultez ensuite Configurer Sophos SSL VPN avec Sophos Connect sur 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 fondamentale entre IPsec, SSL VPN, clients mobiles et ZTNA, consultez d’abord Sophos Connect ou SSL VPN : Quelle solution d’accès distant convient ?.

Quel article SSL VPN convient ?

Le SSL VPN se compose de la configuration du pare-feu, du portail, du client, de l’authentification et de l’analyse des erreurs ultérieure. Selon la tâche, un point d’entrée différent est approprié :

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

Image cible

Une configuration SSL VPN propre se compose de plusieurs éléments :

1. Les utilisateurs ou groupes sont autorisés dans la bonne politique SSL VPN.
2. Les paramètres globaux SSL VPN définissent la passerelle, le port, le certificat, la plage de bail, le DNS et la cryptographie.
3. Le portail VPN est accessible aussi largement que nécessaire et protégé par MFA.
4. Les règles de pare-feu autorisent le trafic depuis la zone VPN uniquement vers les destinations nécessaires.
5. Le tunnel fractionné ou le tunnel complet est décidé consciemment.
6. Les clients importent un profil .ovpn à jour.
7. Les journaux, la capture de paquets et les données de support peuvent être évalués en cas de problème.

De nombreux problèmes SSL VPN surviennent parce que seul le téléchargement du client est documenté. En pratique, il faut considérer ensemble le portail, l’authentification, la politique SSL VPN, la règle de pare-feu, le DNS et le NAT.

⚠️ Le SSL VPN est un point d’entrée accessible au public. Le MFA et les mots de passe forts sont importants, mais ne remplacent pas une limitation via Device access, des groupes d’utilisateurs restreints, des profils à jour, la journalisation et des examens réguliers.

Prérequis

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

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

Si Microsoft Entra ID SSO doit être utilisé, l’authentification doit être correctement préparée avant le téléchargement de la configuration VPN. Le processus est décrit dans Configurer Microsoft Entra ID SSO pour Sophos Connect et le portail VPN.

1. Préparer les objets locaux

Tout d’abord, les réseaux cibles doivent exister en tant qu’hôtes ou objets réseau :

Hosts and services > IP host

Objets typiques :

Il ne faut pas simplement autoriser des plages de réseau internes complètes si seuls certains serveurs ou sous-réseaux sont nécessaires. Plus les objets sont définis de manière stricte, plus la règle de pare-feu sera simple par la suite.

2. Vérifier les paramètres globaux SSL VPN

Les paramètres globaux s’appliquent à toutes les politiques SSL VPN d’accès distant :

Remote access VPN > SSL VPN > SSL VPN global settings

Protocole et port

Le SSL VPN peut utiliser TCP ou UDP selon la configuration. L’UDP est souvent plus efficace, tandis que le TCP peut mieux fonctionner dans les réseaux restrictifs. La décision doit être testée avec les réseaux à partir desquels les utilisateurs travaillent réellement.

Il faut éviter les chevauchements de ports :

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

Si WAF, le portail VPN, le portail utilisateur et le SSL VPN sont exploités sur la même IP WAN, il est conseillé de documenter consciemment le port, le protocole et le certificat. Pour les bases du WAF, consultez Configurer Sophos Firewall WAF et éviter les erreurs courantes.

Certificat et nom d’hôte de remplacement

Sous SSL server certificate, un certificat correspondant au FQDN public doit être utilisé. Une erreur de certificat dans le portail VPN ou le profil SSL VPN entraînera plus tard des cas de support inutiles.

Sous Override hostname, on définit le nom d’hôte ou l’adresse IP que les clients utiliseront dans le profil .ovpn. Cela est particulièrement important dans les cas suivants :

• plusieurs adresses IP WAN,
• routeur en amont,
• NAT ou transfert de port avant le pare-feu,
• IP WAN dynamique avec DDNS,
• FQDN séparés pour WebAdmin, le portail VPN et le SSL VPN.

Si le champ reste vide, plusieurs adresses d’interface peuvent se retrouver dans le profil. Cela peut fonctionner, mais est souvent moins clair qu’un FQDN propre dans les environnements de production.

Plage de bail

Sophos Firewall attribue aux clients SSL VPN des adresses à partir de la plage de bail configurée. Cette plage ne doit pas entrer en conflit avec les réseaux internes, les routes statiques, les VPN site-à-site ou les plages de réseau domestiques typiques.

Il est particulièrement conseillé d’éviter les sous-réseaux 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

Si la plage de bail entre en conflit avec le réseau domestique d’un utilisateur, le tunnel peut parfois se connecter avec succès, mais les cibles internes restent inaccessibles. Cela ressemble alors à un problème de règle de pare-feu, mais c’est un problème de routage sur le point d’extrémité.

Pour les règles de pare-feu, il est conseillé d’utiliser les hôtes système ##ALL_SSLVPN_RW et pour IPv6 ##ALL_SSLVPN_RW6, et non des hôtes recréés manuellement avec d’anciennes plages de bail.

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

Les adresses IP SSL VPN statiques peuvent être utiles dans certains cas, par exemple pour les accès administratifs, les accès spéciaux strictement enregistrés ou les applications héritées avec autorisation basée sur l’IP. Cependant, elles ne conviennent pas comme standard pour tous les utilisateurs. Plus il y a d’attributions statiques, plus l’exploitation, l’analyse des erreurs et les migrations ultérieures deviennent difficiles.

Un cas particulier est documenté dans la liste des problèmes connus : avec le SSL VPN utilisant l’authentification locale et une IP SSL VPN statique attribuée, la réauthentification après l’expiration de la durée de vie des clés peut échouer. 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 typique de durée de vie des clés est 18000 secondes.

Si un utilisateur doit se reconnecter après plusieurs heures, il ne faut pas seulement vérifier le MFA, la version du client et la règle de pare-feu. Ces points doivent également être inclus dans l’analyse :

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

Sophos propose deux mesures pragmatiques : planifier la durée de vie des clés pour couvrir la journée de travail normale, ou utiliser l’attribution d’IP dynamique. Dans de nombreux environnements, l’attribution dynamique est plus propre, car les règles de pare-feu devraient de toute façon être contrôlées via 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 internes, les paramètres globaux SSL VPN définissent les serveurs DNS et éventuellement un nom de domaine. 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, sous Administration > Device access, le DNS doit être autorisé depuis la zone VPN si le pare-feu lui-même est utilisé comme résolveur DNS dans la conception VPN.

Si le DNS ne fonctionne pas dans le tunnel, il faut tester séparément :

• La cible est-elle accessible par adresse IP ?
• Le serveur DNS interne est-il autorisé par la règle de pare-feu ?
• Le client reçoit-il le bon domaine de recherche ?
• Le client utilise-t-il vraiment le profil .ovpn actuel ?
• La configuration DNS locale ou DoH du point d’extrémité interfère-t-elle ?

3. Créer une politique SSL VPN

La politique est créée sous :

Remote access VPN > SSL VPN

Procédure :

1. Sélectionner Add.
2. Utiliser Configure manually.
3. Attribuer un nom, par exemple SSLVPN-Remote-Users.
4. Sous Policy members, sélectionner les utilisateurs ou groupes autorisés.
5. Définir le tunnel fractionné ou le tunnel complet.
6. Pour le tunnel fractionné, sélectionner les Permitted network resources.
7. Configurer éventuellement Disconnect idle clients.
8. Enregistrer et tester ensuite avec un utilisateur de test.

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

4. Décider entre tunnel fractionné ou tunnel complet

Tunnel fractionné

Avec le tunnel fractionné, seul le trafic vers les ressources internes autorisées passe par le tunnel VPN. Le trafic Internet de l’utilisateur continue de passer directement par le réseau local de l’utilisateur.

Le tunnel fractionné est souvent adapté pour :

• Accès à quelques applications internes,
• Charge réduite sur le pare-feu,
• Meilleure performance utilisateur,
• Petits sites distants et utilisateurs mobiles.

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

Tunnel complet

Avec le tunnel complet, tout le trafic de l’utilisateur distant est acheminé via le pare-feu. Sur Sophos Firewall, cela correspond à l’option Use as default gateway.

Le tunnel complet est plus adapté lorsque :

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

Avec le tunnel complet, la politique SSL VPN seule ne suffit pas. Des règles de pare-feu et NAT/SNAT pour le trafic Internet depuis la zone VPN sont également nécessaires. De plus, il est conseillé de tester la performance, la bande passante, le filtrage Web et la journalisation au préalable.

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

L’établissement du tunnel ne signifie pas que le trafic est autorisé. Pour accéder aux ressources internes, une règle de pare-feu appropriée est nécessaire :

Rules and policies > Firewall rules

Règle recommandée pour le tunnel fractionné :

Pour le tunnel complet, une règle supplémentaire de VPN vers WAN ou Any est nécessaire, selon la conception. Les réseaux sources doivent toujours être les hôtes système SSL VPN. Ensuite, il faut vérifier si une règle SNAT appropriée existe.

Si une connexion est établie mais qu’aucun accès ne fonctionne, il est conseillé de vérifier d’abord le Log Viewer. Pour la méthodologie, consultez Tester la règle de pare-feu avec Log Viewer, Policy Test et Packet Capture.

6. Sécuriser le portail VPN et l’accès au dispositif

Les utilisateurs téléchargent généralement Sophos Connect et le fichier .ovpn via le portail VPN :

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

Vérifications minimales :

• Port et certificat du portail VPN.
• Méthodes d’authentification du portail VPN.
• MFA pour le portail VPN et l’accès distant.
• Accès au dispositif pour VPN Portal uniquement dans les zones nécessaires.
• Accès au dispositif pour SSL VPN sur la zone WAN uniquement si nécessaire en externe.
• Pas de portail utilisateur ouvert en permanence sur le WAN si non nécessaire.

Pour le renforcement des services locaux du pare-feu, consultez Accès au dispositif et ACL de service local sur Sophos Firewall. Pour les bases du MFA, consultez Activer le MFA pour Sophos Firewall WebAdmin, le portail VPN et l’accès distant.

Le portail VPN n’apparaît utile aux utilisateurs que s’ils ou leurs groupes sont inclus dans une politique d’accès distant appropriée. Si l’association de politique manque, l’utilisateur ne voit pas les téléchargements de configuration nécessaires.

Si le portail VPN ou le SSL VPN doivent être autorisés sur la zone WAN, cela doit être documenté consciemment. Dans de nombreux environnements, il ne suffit pas d’ouvrir le service mondialement et de se fier au MFA. Là où c’est possible, il est conseillé d’examiner les réseaux sources fixes, la limitation par pays, les flux de menaces, la vérification des journaux ou une conception d’accès distant en amont.

7. Distribuer le profil client

Après la configuration de la politique et du portail, le fichier .ovpn est distribué. Cela peut se faire via le portail VPN ou de manière contrôlée par le processus administratif.

Important :

• Après des modifications du portail, du port, du certificat, du DNS, de la plage de bail, de la politique 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 clairs.
• Les anciens profils doivent être supprimés lors d’un changement de site, de passerelle ou d’utilisateur.
• Windows, macOS, iOS, Android et Linux utilisent parfois des chemins clients différents.

Pour les mises à jour des clients et la gestion des versions, consultez Vérifier et mettre à jour en toute sécurité la version du client Sophos Connect.

Tester après la configuration

Avec un utilisateur de test, il ne faut pas seulement vérifier si Sophos Connect affiche Connected.

Liste de tests :

• L’utilisateur voit le téléchargement de Sophos Connect et la configuration SSL VPN dans le portail VPN.
• Le fichier .ovpn peut être importé.
• Le MFA est demandé comme prévu.
• Le client reçoit une adresse de la plage de bail SSL VPN.
• La route vers les réseaux internes autorisés apparaît sur le point d’extrémité.
• Les noms DNS internes sont résolus.
• L’accès aux serveurs autorisés fonctionne.
• Les réseaux non autorisés restent bloqués.
• Le Log Viewer montre la bonne règle de pare-feu.
• La capture de paquets montre le trafic via une interface tun, si nécessaire.
• Avec le tunnel complet, l’accès Internet et le SNAT fonctionnent également.

Si le test est effectué uniquement avec un utilisateur administrateur, les erreurs de groupe et de politique peuvent facilement être négligées. Il est préférable d’utiliser un utilisateur pilote normal du groupe cible.

Test d’acceptation par scénario

Avant un déploiement large, il est conseillé de documenter au moins ces cas de test de manière claire :

Pour les environnements de production, chaque test doit inclure une heure, un utilisateur, une plateforme client et un objectif concret. Des déclarations comme “VPN fonctionne” ou “VPN ne fonctionne pas” sont trop vagues pour les cas de support ultérieurs.

Collecter les journaux et preuves

En cas de problèmes SSL VPN, il est conseillé de déterminer d’abord si l’erreur se situe lors de la connexion, de l’établissement du tunnel ou de l’accès aux cibles internes. Cette séparation permet de gagner du temps, car sinon l’authentification, le profil client, le routage et les règles de pare-feu sont vérifiés de manière désordonnée.

Pour un cas de test reproductible, ces informations doivent être notées :

Ensuite, il est conseillé de procéder à la vérification dans cet ordre :

1. Vérifier l’authentification : Dans le Log Viewer et, si nécessaire, dans les journaux d’authentification, vérifier si l’utilisateur, le MFA, le groupe et le serveur d’authentification sont réussis. Avec Microsoft Entra ID SSO, oauth_sso_vpn.log est également pertinent.
2. Vérifier l’état du tunnel : Vérifier la connexion SSL VPN, l’adresse de bail et l’état OpenVPN. Côté pare-feu, sslvpn.log et openvpn-status*.log sont utiles.
3. Vérifier la règle de pare-feu : Dans le Log Viewer, rechercher le trafic depuis la zone VPN et vérifier quelle règle correspond réellement. La règle doit avoir Log firewall traffic activé.
4. Vérifier le flux de paquets : Si le Log Viewer ne suffit pas, filtrer avec Packet Capture sur la source, la destination et le service. Il est important de savoir si les paquets sont uniquement Incoming ou également Forwarded.
5. Vérifier le côté cible : Si le trafic quitte le pare-feu mais qu’aucune réponse ne revient, une route de retour, le pare-feu du serveur, le pare-feu local de l’hôte ou un conflit réseau sont plus probables que la politique SSL VPN.

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

Dépannage

L’utilisateur ne voit pas la configuration SSL VPN dans le portail VPN

Il manque généralement l’association de politique. Il est conseillé de vérifier si l’utilisateur ou son groupe est inclus dans la politique SSL VPN sous Policy members. De plus, l’authentification, le MFA et l’accessibilité du portail VPN doivent être vérifiés.

Si la connexion et l’association de politique semblent correctes, mais que le téléchargement du fichier .ovpn manque ou échoue, il est également conseillé de vérifier la limite d’ID utilisateur Sophos Firewall. Cela est particulièrement pertinent si plusieurs utilisateurs utilisent le portail, mais que seuls certains téléchargements échouent de manière inattendue.

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

Il est conseillé de vérifier d’abord si une route vers le réseau cible interne existe sur le point d’extrémité. Ensuite, rechercher le trafic depuis la zone VPN dans le Log Viewer. 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 que la mauvaise règle s’applique, il faut corriger l’ordre des règles ou la définition du service/destination. Si aucune réponse ne revient, le routage, le pare-feu cible, le pare-feu local du serveur ou un conflit réseau sont probables.

Le DNS ne fonctionne pas

Il est conseillé de vérifier si l’accès par adresse IP fonctionne. Si oui, l’erreur est probablement liée au DNS. Ensuite, vérifier les serveurs DNS dans les paramètres globaux SSL VPN, le nom de domaine, l’accès au dispositif pour le DNS depuis la zone VPN et le comportement DNS du point d’extrémité.

L’accès fonctionne uniquement pour certains utilisateurs

Dans ce cas, l’appartenance à un groupe, l’association de politique, les adresses IP SSL VPN statiques, le statut MFA ou les profils obsolètes sont plus probables qu’une erreur de pare-feu globale. Les associations de politique en double doivent également être vérifiées.

L’utilisateur doit se reconnecter après plusieurs heures

Si le SSL VPN fonctionne initialement, mais qu’une nouvelle connexion ou une reconnexion manuelle est nécessaire après plusieurs heures, il est conseillé de vérifier d’abord les modèles temporels, l’authentification et le modèle de bail. Cela est particulièrement pertinent avec l’authentification locale et une IP SSL VPN statique attribuée.

Procédure pratique :

1. Noter l’heure de la connexion et de la déconnexion.
2. Comparer le moment avec la durée de vie des clés configurée.
3. Vérifier si l’utilisateur a une adresse IP SSL VPN statique.
4. Tester l’attribution d’IP dynamique pour un utilisateur pilote, si possible opérationnellement.
5. Rechercher dans sslvpn.log, openvpn-status*.log et Log Viewer l’authentification, l’adresse de bail et la reconnexion.
6. Si une durée de vie des clés plus longue est choisie, documenter le changement et ne pas le considérer comme un remplacement du MFA ou d’un contrôle de session propre.

Si des IP statiques sont utilisées uniquement pour simplifier les règles de pare-feu, il est conseillé de revoir la conception. En général, les groupes, les objets cibles clairement nommés, les services restreints et la journalisation constituent une meilleure base que les adresses IP utilisateur individuelles.

Le tunnel complet n’a pas d’accès Internet

Avec Use as default gateway, une règle de pare-feu pour le trafic depuis la zone VPN vers Internet et une règle SNAT appropriée sont nécessaires. De plus, les politiques Web, DNS et de sécurité doivent être planifiées de manière à ne pas bloquer les utilisateurs VPN de manière inattendue.

La connexion est établie, mais les transferts importants sont bloqués

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 importants sont bloqués, il est conseillé de vérifier le MTU et le MSS. Le symptôme correspond souvent à une fragmentation, un PPPoE, des connexions tunnelisées ou un chemin asymétrique, pas seulement au SSL VPN lui-même.

Pour une analyse systématique, consultez Vérifier MTU et MSS de Sophos Firewall en cas de problèmes VPN.

WAF ou portail entre en collision avec SSL VPN

Si WAF, le portail VPN, le portail utilisateur et le SSL VPN fonctionnent sur la même IP WAN, le port et le protocole doivent être séparés proprement. Les combinaisons partagées d’IP WAN, de port et de TCP sont particulièrement critiques. En cas de drops non clairs, vérifier le Log Viewer et la capture de paquets.

Le profil est obsolète après modification

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

Liste de vérification opérationnelle

Avant le déploiement en production

• FQDN et certificat pour le portail VPN et le SSL VPN vérifiés.
• La plage de bail SSL VPN ne entre pas en conflit avec les réseaux internes ou domestiques typiques.
• La politique SSL VPN contient les bons utilisateurs ou groupes.
• Le tunnel fractionné ou le tunnel complet est décidé consciemment.
• Les ressources réseau autorisées sont strictement définies pour le tunnel fractionné.
• Les serveurs DNS et le nom de domaine sont correctement définis.
• Une règle de pare-feu de VPN vers les cibles internes existe et journalise.
• Pour le tunnel complet, une règle Internet et SNAT existent.
• L’accès au dispositif pour SSL VPN et VPN Portal est défini consciemment.
• Le MFA est testé pour l’accès distant.
• L’utilisateur de test peut télécharger, importer le profil et atteindre les cibles internes.

Pour l’exploitation continue

• Imposer le MFA pour le portail VPN et l’accès distant.
• Vérifier régulièrement les groupes VPN.
• Garder les règles de pare-feu pour VPN strictes et les journaliser.
• Contrôler la plage de bail avant les changements de réseau.
• Utiliser les adresses IP SSL VPN statiques uniquement de manière ciblée et les vérifier régulièrement.
• Documenter le DNS et le domaine de recherche.
• Renouveler les certificats du portail et du SSL VPN avant leur expiration.
• Suivre les versions de Sophos Connect.
• Planifier la redistribution du profil après les modifications.
• Évaluer les journaux à long terme via Syslog ou Sophos Central si la traçabilité est importante.

Pour les fichiers journaux et les services, consultez Dépannage Sophos Firewall : Services et journaux.

Vérifier régulièrement les cas particuliers

• Les adresses IP SSL VPN statiques sont justifiées et documentées.
• La durée de vie des clés correspond au modèle opérationnel et a été testée avec reconnexion.
• L’ancien profil .ovpn est redistribué après les modifications.
• Le portail VPN, le portail utilisateur, le WAF et le SSL VPN ne se chevauchent pas sur la même IP WAN avec le port et le protocole.
• Les utilisateurs avec des droits spéciaux ou un accès administrateur sont vérifiés séparément.

FAQ