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

L’accès à distance SSL VPN se configure sur Sophos Firewall sous Remote access VPN > SSL VPN. Six éléments doivent fonctionner ensemble pour sécuriser l’accès :

Affecter les utilisateurs ou les groupes à une stratégie SSL VPN.
Configurer globalement le protocole, le certificat, la gateway, la plage d’attribution et le DNS.
Choisir délibérément Split Tunnel ou Use as default gateway.
Autoriser le trafic de la zone VPN avec des règles de pare-feu strictes.
Sécuriser VPN Portal, l’authentification, le MFA et Device Access.
Distribuer un profil .ovpn à jour ou, sous Windows, un fichier de provisioning .pro, puis tester les accès autorisés et bloqués.

⚠️ SSL VPN est un point d’entrée accessible publiquement. Le MFA et des mots de passe robustes ne remplacent pas des groupes d’utilisateurs restreints, des Local Service ACL, des règles de pare-feu précises, des profils à jour, des journaux et des contrôles réguliers.

Cet article traite de la configuration côté pare-feu. L’installation du client est documentée séparément pour Windows, macOS, iPhone et iPad, Android et Linux. Pour choisir au préalable entre SSL VPN, IPsec et ZTNA, consulter Sophos Connect ou SSL VPN.

Préparer les prérequis et les objets

Avant la configuration, définir l’accès public, les utilisateurs autorisés et les destinations internes :

version actuelle de SFOS et client Sophos Connect à jour ;
FQDN public ou adresse IP publique ;
certificats pour le tunnel SSL VPN et VPN Portal ;
utilisateurs ou groupes et serveur d’authentification ;
méthode MFA pour le portail et le tunnel ;
plage d’attribution SSL VPN sans chevauchement ;
réseaux de destination internes, serveurs DNS et domaine de recherche ;
choix entre Split Tunnel et Full Tunnel ;
processus de distribution des profils et de mise à jour des clients.

Créer d’abord les destinations internes sous forme d’hôtes ou d’objets réseau :

Hosts and services > IP host

L’exemple suivant utilise :

LAN_Server : 10.10.10.0/24 pour les serveurs internes ;
LAN_Client : 10.10.20.0/24 si les utilisateurs distants ont réellement besoin de ce réseau client ;
DNS_Internal : 10.10.10.10 pour le serveur DNS interne ou le contrôleur de domaine ;
SSLVPN_Users : groupe d’utilisateurs pour les policy members.

Ne pas autoriser des réseaux internes entiers lorsque quelques serveurs ou sous-réseaux suffisent. Les serveurs DNS ont également besoin d’un objet clairement défini afin que la route et la règle de pare-feu restent compréhensibles.

Configurer les paramètres globaux SSL VPN

Les paramètres globaux s’appliquent à toutes les stratégies Remote Access SSL VPN et font partie de la configuration .ovpn :

Remote access VPN > SSL VPN > SSL VPN global settings

Ces valeurs sont également utilisées pour les connexions SSL Site-to-Site entre deux Sophos Firewall. Lors d’une modification du port, du protocole, du certificat ou d’Override hostname, il faut donc vérifier à la fois les profils Remote Access et les tunnels SSL Site-to-Site existants, puis redistribuer leurs configurations.

Avant de modifier les valeurs globales du profil, consigner Protocol, Port, Override hostname, SSL server certificate, les valeurs de la plage d’attribution et du DNS, ainsi que la configuration des pairs SSL Site-to-Site concernés. Inclure également les éventuelles règles NAT ou redirections de port en amont dans le plan de repli. Si le test de validation échoue, rétablir ces valeurs et la configuration Site-to-Site précédente, puis répéter les tests du portail, du tunnel, des accès autorisés et des accès bloqués avec l’ancien profil.

Protocole, certificats, gateway et port

SSL VPN prend en charge TCP et UDP. UDP constitue généralement le choix initial le plus efficace ; TCP peut servir d’alternative testée lorsque des réseaux externes bloquent UDP. Tester le choix depuis de vrais réseaux d’hôtel, mobiles ou invités.

Le port par défaut de SSL VPN est 8443, tandis que VPN Portal utilise 443 par défaut. Une combinaison distincte d’adresse IP WAN, de port et de protocole pour chaque service accessible publiquement simplifie la compréhension et l’exploitation.

Sophos utilise deux certificats distincts :

Le SSL server certificate sélectionné dans les paramètres globaux SSL VPN est utilisé par le serveur SSL VPN.
Le certificat HTTPS de VPN Portal se sélectionne sous Administration > Admin and user settings.

Les deux certificats doivent correspondre au FQDN public utilisé pour le service concerné. Pour les certificats délivrés par une autorité de certification externe, la chaîne de certificats nécessaire doit également être disponible.

Override hostname définit le FQDN ou l’adresse IP publique du profil client. Ce champ est particulièrement important avec un NAT en amont, plusieurs interfaces WAN ou DDNS. S’il reste vide, le profil peut contenir plusieurs adresses d’interface. Sophos Connect donne la priorité aux gateways DDNS et tente les autres entrées dans l’ordre inverse ; un FQDN unique est donc plus simple à tester et à exploiter.

VPN Portal et SSL VPN peuvent techniquement partager le même port et le même protocole. Dans ce cas, les paramètres de sécurité de connexion ne fonctionnent pas comme prévu et VPN Portal devient accessible depuis les zones activées pour SSL VPN. WAF doit se distinguer de VPN Portal par l’adresse IP WAN ou le port, et de SSL VPN par l’adresse IP WAN, le port ou le protocole. Sophos Firewall WAF explique les autres dépendances WAF.

Plage d’attribution et DNS

La plage d’attribution IPv4 doit être privée et ne doit chevaucher ni les réseaux internes, ni les VPN Site-to-Site, ni les routes statiques, ni les autres pools Remote Access, ni les réseaux domestiques courants. Les exemples fréquents sont 192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24, 10.0.0.0/24 et 10.0.1.0/24.

La documentation de SFOS 22 se contredit au sujet du préfixe autorisé pour les petites plages IPv4. L’aide du champ indique que /24 est la limite et que les sous-réseaux /25 ou plus petits ne peuvent pas être sélectionnés, tandis que la FAQ actuelle décrit aussi des sous-réseaux plus petits répartis en interne entre plusieurs instances OpenVPN. La version de SFOS utilisée fait donc foi : vérifier quel préfixe son interface propose, puis contrôler le nombre réel d’adresses disponibles.

Selon la FAQ Sophos, le nombre d’instances SSL VPN simultanées dépend des CPU du modèle de pare-feu. Chaque instance crée une interface tun0 et nécessite son propre sous-réseau pour le routage et la distribution interne. SFOS subdivise le pool configuré ; ces adresses sont consommées avant l’attribution des baux clients. La FAQ illustre ce mécanisme avec 192.168.0.0/27, huit instances simultanées et une seule adresse IP encore attribuable. Ce n’est ni une capacité universelle ni un réseau d’exemple recommandé : vérifiez les baux réels sur le build et le modèle cibles ; le conflit entre aide du champ et FAQ décrit ci-dessus subsiste.

SFOS 23 : La plage IPv4 sélectionnable dépend du modèle de pare-feu ; les modèles plus grands prennent en charge des sous-réseaux contenant davantage d’adresses IP. L’aide de SFOS 23 indique /24 comme le plus petit sous-réseau sélectionnable. Il s’agit d’une limite de sélection propre au modèle, pas d’une garantie du nombre de baux clients. La répartition interne selon les CPU explique la consommation d’adresses, mais pas les plages de sélection prises en charge. Cela ne résout pas le conflit de SFOS 22 et ne transforme pas l’illustration /27 en recommandation de configuration.

Avant de modifier la plage, consigner le build SFOS, le modèle, la plage précédente et les attributions statiques, puis conserver les anciennes valeurs pour le retour arrière. Sélectionner dans l’interface uniquement une plage prise en charge par le modèle cible, maintenir les adresses statiques des utilisateurs dans la plage statique résultante et vérifier les baux réellement disponibles. Reconnecter ensuite un utilisateur pilote et tester le bail, le DNS ainsi que les destinations autorisées et bloquées. Si la validation échoue, restaurer les valeurs et attributions précédentes et refaire les tests. Si le build, l’interface, l’aide ou la FAQ se contredisent, arrêter le déploiement de capacité qui en dépend jusqu’à clarification avec le support ; ne pas forcer un masque.

API XML SFOS 23 – statut 551 : La ligne de statut brute pour Configure SSLVPN Tunnel Access renvoie à l’identifiant d’exécution non résolu Message.SSLVPNInvalidLeaseIPv4Mask. Elle ne permet de déduire ni un libellé de message confirmé, ni une cause de rejet établie, ni une nouvelle plage de masques prise en charge. Si l’API renvoie 551, conserver la réponse complète et les paramètres précédents. Avant toute modification, vérifier StartIP, SubnetMask et les choix de pool pris en charge par le build installé et le modèle, à l’aide de la documentation approuvée pour cet environnement ou avec Sophos Support ; ne pas forcer un masque.

Après une correction prise en charge, vérifier la réponse de l’API, les paramètres réellement enregistrés sur le pare-feu cible et le bail d’un utilisateur pilote reconnecté. Conserver les anciennes valeurs et attributions pour le retour arrière décrit ci-dessus. Si le diagnostic ou le libellé du message reste déterminant pour l’approbation et non résolu, maintenir le déploiement en attente.

Une petite plage ne constitue pas un contrôle d’accès ; celui-ci repose sur la stratégie et les règles de pare-feu. Dans les règles, utiliser les hôtes système ##ALL_SSLVPN_RW et, pour IPv6, ##ALL_SSLVPN_RW6.

Saisir les serveurs DNS internes sous IPv4 DNS. Domain name contient le domaine de recherche ajouté aux noms d’hôte courts. Avec Split Tunnel, le serveur DNS ou son réseau doit également figurer sous Permitted network resources et être autorisé par une règle de pare-feu depuis la zone VPN. Avec Full Tunnel, la route Split Tunnel n’est pas nécessaire, mais la règle de pare-feu reste indispensable.

Si le pare-feu sert lui-même de résolveur DNS, saisir son adresse appropriée sous IPv4 DNS. Autoriser également DNS pour la zone VPN sous Administration > Device access. Un test par adresse IP, puis un autre par nom d’hôte, permet de distinguer un problème de routage d’un problème DNS.

Adresses IP statiques, sessions parallèles et temporisations

Les adresses IP SSL VPN statiques sont possibles pour des exceptions justifiées, par exemple une autorisation héritée basée sur l’adresse IP, et doivent rester dans le pool configuré. Un utilisateur possédant une adresse IP SSL VPN statique ne peut toutefois pas établir plusieurs sessions Remote Access en parallèle.

Indépendamment de cela, Simultaneous logins sous Authentication > Services ou directement sur l’utilisateur local limite les connexions parallèles. La valeur globale ne s’applique qu’aux utilisateurs créés par la suite.

Key lifetime contrôle le renouvellement des clés ; il ne s’agit ni d’un délai d’inactivité ni d’une durée maximale de session. Les connexions inactives sont contrôlées par les paramètres globaux d’inactivité et, facultativement, par Disconnect idle clients dans la stratégie. En cas de déconnexion inattendue, contrôler séparément ces valeurs, l’attribution d’une adresse IP statique, les connexions parallèles et les journaux.

Disconnect dead peer after est une valeur globale exprimée en secondes et ferme les connexions des clients qui ne répondent plus. Les valeurs par défaut sont de 180 secondes pour TCP et de 100 secondes pour UDP ; SFOS accepte de 60 à 110 pour UDP. Disconnect idle peer after est en revanche exprimé en minutes et ferme les sessions réellement inactives. Avant d’augmenter une valeur, utiliser sslvpn.log, le journal du client et les preuves de perte de paquets pour déterminer quel minuteur se déclenche réellement.

Le paramètre Override global timeout d’une stratégie peut uniquement raccourcir la valeur d’inactivité globale. Si la valeur de la stratégie est supérieure, la valeur globale continue de s’appliquer. Une ancienne page de dépannage Sophos recommande une valeur de stratégie supérieure pour certains utilisateurs, mais l’aide actuelle des champs SFOS 22 contredit explicitement cette recommandation. Pour autoriser des sessions plus longues, ne pas augmenter inutilement la valeur de la stratégie ; adapter la valeur globale après une analyse d’impact, puis refaire le test avec le même groupe d’utilisateurs.

Créer la stratégie SSL VPN

Créer la stratégie manuellement ou avec l’assistant :

Remote access VPN > SSL VPN

Sophos recommande l’assistant, en particulier pour la première stratégie SSL VPN. Il affiche les paramètres globaux pour contrôle, mais ne permet pas de les modifier. Il applique les serveurs et méthodes d’authentification sélectionnés, configure Device Access pour VPN Portal et SSL VPN, puis crée la stratégie et la règle de pare-feu. À la première utilisation, il crée le groupe de règles Automatic VPN rules en tête de la table des règles et active la nouvelle règle. Les règles créées ensuite par l’assistant sont placées à la fin de ce groupe. Après chaque exécution, vérifier leur position et la Rule ID qui correspond réellement. Dans un environnement existant, Configure manually est souvent plus transparent :

Sélectionner Add > Configure manually.
Saisir un Name, par exemple SSLVPN-Remote-Users.
Sous Policy members, sélectionner le groupe SSLVPN_Users.
Choisir Split Tunnel ou Use as default gateway.
Avec Split Tunnel, sélectionner LAN_Server et DNS_Internal comme Permitted network resources. Utiliser ici des objets réseau ou hôte, et non des interfaces : sélectionner une interface ne garantit pas l’accès à son sous-réseau.
Configurer facultativement Disconnect idle clients et Override global timeout.
Enregistrer, puis vérifier le résultat avec un membre ordinaire du groupe cible.

Les utilisateurs et groupes invités ne peuvent pas servir de policy members. Si un utilisateur ou un groupe figure déjà dans une ancienne stratégie SSL VPN, SFOS supprime son affectation de la stratégie précédente. Vérifier les chevauchements avant l’enregistrement.

Un Override global timeout propre à la stratégie ne prend effet que s’il est inférieur à la valeur d’inactivité globale. Une valeur supérieure ne remplace pas la limite globale.

Split Tunnel ou Full Tunnel

Avec Split Tunnel, seuls les réseaux IPv4 et IPv6 ainsi que les destinations FQDN prises en charge sous Permitted network resources passent par le VPN. Les destinations FQDN ne sont prises en charge qu’en IPv4. Tout le reste du trafic Internet demeure local. Cette approche réduit la charge du pare-feu et la latence, mais exige une planification précise des ressources et du DNS.

Si l’adresse IP d’une destination FQDN autorisée change, les tunnels existants ne sont pas actualisés automatiquement. Les utilisateurs concernés doivent se déconnecter, puis se reconnecter.

Avec Full Tunnel, activer Use as default gateway. Tout le trafic de l’utilisateur passe alors par le pare-feu. Dans ce mode, Permitted network resources n’est pas appliqué comme limite d’accès. Les règles de pare-feu doivent restreindre les destinations et services internes, et l’accès Internet IPv4 nécessite en plus une règle SNAT/MASQ adaptée.

Full Tunnel permet de centraliser le contrôle du web, du DNS et des journaux, mais augmente les besoins en bande passante, la charge du pare-feu, les considérations de protection des données et la charge de support. Le tester avec les applications réelles et le nombre prévu d’utilisateurs simultanés.

Règles de pare-feu, Device Access et authentification

Règles de pare-feu et DNS

L’établissement du tunnel n’autorise pas encore l’accès aux ressources internes. Créer une règle de pare-feu :

Rules and policies > Firewall rules

Exemple pour Split Tunnel :

Rule name : VPN_SSLVPN_to_Internal_Servers
Action : Accept
Source zone : VPN
Source networks and devices : ##ALL_SSLVPN_RW
Destination zones : LAN
Destination networks : LAN_Server, DNS_Internal
Services : uniquement les services applicatifs nécessaires et DNS
Log firewall traffic : activé

Placer cette règle au-dessus des règles VPN plus générales. Un test négatif vers une destination interdite montre si une règle générale située plus bas autorise involontairement le trafic.

Pour Full Tunnel IPv4, ajouter une règle de VPN vers WAN et une règle SNAT/MASQ adaptée. IPv6 nécessite à la place un routage IPv6 délibéré et des règles de pare-feu IPv6 distinctes. En cas d’échec, utiliser Log Viewer, Rule ID et la procédure de test des règles de pare-feu.

VPN Portal, Device Access et MFA

Contrôler le portail, les services locaux et l’authentification à des emplacements distincts :

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

Configurer au minimum :

SSL VPN dans les zones depuis lesquelles le tunnel peut être établi ;
VPN Portal uniquement dans les zones réellement nécessaires ;
DNS dans la zone VPN uniquement lorsque le pare-feu sert de résolveur ;
les VPN portal authentication methods appropriées ;
les SSL VPN authentication methods appropriées ;
le MFA pour le portail et le tunnel.

Lorsqu’une méthode d’authentification contient plusieurs serveurs, SFOS leur transmet les requêtes dans l’ordre affiché. Chaque méthode peut contenir jusqu’à 20 serveurs. Vérifier délibérément cet ordre lorsque des noms d’utilisateur identiques ou un mécanisme de repli sont en jeu, afin d’identifier le serveur qui traite réellement la requête.

Les règles de pare-feu normales ne contrôlent pas ces services locaux. Restreindre les réseaux sources, les adresses IP individuelles ou les pays avec des Local Service ACL Exception Rules. La procédure de sécurisation complète est documentée sous Device Access et Local Service ACL.

Le proxy web du pare-feu constitue un cas particulier : les requêtes HTTP et HTTPS qui le traversent sont considérées comme internes pour les services locaux. Les utilisateurs ayant accès au proxy peuvent donc atteindre VPN Portal même s’il n’est pas activé pour leur zone source. Lorsque le proxy est utilisé, tester cette accessibilité séparément au lieu de se fier uniquement à la matrice des zones sous Device Access.

Les Third-party Threat Feeds peuvent également bloquer les accès aux services VPN destinés au système. Ils permettent de bloquer en complément des sources indésirables connues ; Threat Feeds sur Sophos Firewall en explique la configuration et les limites.

Les VPN portal authentication methods contrôlent la connexion au portail et le téléchargement du profil, tandis que les SSL VPN authentication methods contrôlent la connexion au tunnel. WebAdmin est une interface d’administration distincte et n’a pas besoin d’être exposée à la zone WAN pour SSL VPN.

SSO selon la version de SFOS : Sous SFOS 22, configurer Microsoft Entra ID avec Server type: Microsoft Entra ID SSO. Sous SFOS 23, ouvrir Authentication > Servers > Add, sélectionner Server type: OpenID Connect, puis IdP vendor: Microsoft Entra ID ou IdP vendor: Google Workspace. La configuration de l’application, du serveur, des Redirect URIs et des groupes est décrite dans Microsoft Entra ID SSO pour Sophos Connect et Google Workspace OIDC sur Sophos Firewall, respectivement. Ces variantes ne confirment pas la disponibilité GA d’un build.

Avant de télécharger le profil, sélectionner le même serveur IdP configuré sous Authentication > Services pour VPN portal authentication methods et SSL VPN authentication methods, puis cliquer sur Apply pour chaque service ; sous SFOS 22, il s’agit du même serveur Entra. Comparer la Redirect URI complète chez le fournisseur choisi, avec FQDN, port et chemin, et vérifier les points de terminaison de connexion nécessaires. Un SSO réussi ne remplace ni l’appartenance aux groupes, ni Policy members, ni des règles de pare-feu restrictives. Avant la bascule, conserver les affectations de services, l’ordre des serveurs et les profils fonctionnels. Après modification du SSO, télécharger et importer à nouveau la configuration actuelle, puis tester avec un utilisateur pilote ordinaire le portail, le tunnel, la MFA de l’IdP, le DNS et les destinations autorisées et bloquées. En cas d’échec, restaurer les affectations, l’ordre et les profils correspondants consignés, puis refaire les mêmes tests ; ne pas supprimer l’ancien accès avant validation.

Pour l’OTP natif de SFOS, sélectionner les utilisateurs ou groupes cibles sous Authentication > Multi-factor authentication, puis activer VPN portal et SSL VPN remote access sous Require MFA for. Avec Generate OTP token with next sign-in, l’utilisateur doit d’abord scanner le code QR dans VPN Portal avant de pouvoir commencer le test du tunnel.

VPN Portal ne prend pas en charge l’authentification RADIUS avec un MFA basé sur un challenge. Sophos Connect ne prend pas non plus en charge un challenge OTP : il transmet le mot de passe et l’OTP ensemble. Les méthodes Call et Push sont prises en charge. Tester la méthode retenue avec un utilisateur pilote ordinaire. Les principes de base sont décrits sous MFA pour Sophos Firewall.

Distribuer et mettre à jour le profil client

Si des paramètres globaux affectant le profil changent, tels que le protocole, le port, l’interface, le certificat serveur ou Override hostname, télécharger à nouveau le fichier .ovpn actuel depuis VPN Portal, le distribuer de manière sécurisée et, en cas de déploiement manuel, le réimporter dans le client. Update policy n’est pas la première étape ici et ne remplace pas la réimportation manuelle. Son utilisation documentée concerne une connexion provisionnée via .pro : après une modification du port SSL VPN ou du protocole, y exécuter Update policy ; ce mécanisme de provisioning récupère automatiquement les autres modifications de configuration. Des modifications concernant par exemple le port, la passerelle, le certificat serveur ou le protocole peuvent nécessiter une nouvelle authentification. Une mise à jour du logiciel Sophos Connect ne remplace pas un profil obsolète. Conserver en sécurité le profil dont le bon fonctionnement est connu et les valeurs globales de pare-feu correspondantes pour permettre un retour arrière ; avant une distribution à grande échelle, vérifier le nouvel import avec un utilisateur pilote standard en contrôlant la passerelle et le port, l’authentification/MFA, les routes, le DNS ainsi que les destinations autorisées et bloquées. Si la validation échoue, restaurer ensemble les anciennes valeurs correspondantes et le profil dont le bon fonctionnement est connu, puis répéter les mêmes vérifications.

Après une modification de Override hostname ou du port, vérifier dans le client que le profil nouvellement importé utilise réellement le nouveau nom de gateway et le nouveau port.

Après une modification des Policy members, des Permitted network resources ou de l’adresse IP d’une destination FQDN, une déconnexion et une reconnexion suffisent normalement. Les réseaux autorisés ne sont pas stockés statiquement dans le fichier .ovpn ; SFOS ajoute les ressources propres à l’utilisateur lors de l’établissement du tunnel. Ces modifications n’exigent donc pas un nouveau téléchargement du fichier .ovpn.

.pro récupère IPsec (.scx) et les configurations SSL VPN autorisées pour l’utilisateur (.ovpn) via le VPN Portal, ainsi que les modifications ultérieures ; ce n’est pas un profil de tunnel. Les clients Windows compatibles et Sophos Connect pour macOS à partir de 2.1 sont pris en charge, mais pas le client macOS 2.0 ni les versions antérieures. Le provisioning IPsec nécessite Sophos Connect 2.1 ou ultérieur. Sur le client macOS 2.0, l’import direct et l’actualisation manuelle contrôlée restent nécessaires.

Si la gateway de provisioning ou vpn_portal_port change, adapter et redistribuer le fichier .pro. L’ancien champ user_portal_port n’est accepté que pour des raisons de compatibilité. Lors du premier provisioning avec OTP ou une autre méthode MFA, l’écran de connexion peut apparaître deux fois : d’abord pour télécharger le profil, puis pour établir le tunnel.

Si .pro ne fournit qu’une connexion IPsec ou aucune configuration SSL VPN, contrôler d’abord les policy members, l’appartenance au groupe, l’accessibilité de VPN Portal et l’authentification.

Pour le provisioning SSO avec .pro sous Windows avec Sophos Connect 2.4 ou ultérieur, SFOS 22 décrit Entra ID ; SFOS 23 prend en charge les fournisseurs d’identité OIDC compatibles avec ce parcours, pas n’importe quel fournisseur. Sous Authentication > Services, VPN Portal, IPsec VPN et SSL VPN doivent utiliser le même serveur IdP configuré. gateway contient uniquement le FQDN ou l’adresse IP du pare-feu figurant dans la section Redirect URI de ce serveur, pas l’URI de callback complète ; le port du portail se définit séparément dans vpn_portal_port. Pour le SSO, macOS avec Sophos Connect 2.1 ou ultérieur reste ici limité à Entra ID, sans extension à OIDC en général ; la clarification de compatibilité avant déploiement indiquée ci-dessous reste nécessaire. L’article de provisioning suivant explique les prérequis selon le fournisseur et la version.

Provisioning Sophos Connect avec .pro et GPO décrit la structure JSON complète, les champs MFA, la sélection des passerelles et le déploiement GPO.

Pour Google Workspace SSO, cette procédure se limite à Windows avec Sophos Connect 2.4 ou ultérieur ; les indications Entra pour macOS ne s’appliquent pas à Google. Pour Entra, les pages de présentation mentionnent macOS à partir de 2.1, pas 2.0, tandis que les pages de prérequis ne mentionnent que Windows à partir de 2.4. Cette contradiction reste également ouverte dans l’article détaillé lié : arrêter avant tout déploiement macOS jusqu’à confirmation et test séparés de la prise en charge du build cible, de la plateforme/version du client et du type de VPN requis. Pour chaque parcours approuvé, vérifier les paramètres SFOS compatibles, la configuration client actuelle, les méthodes d’authentification et la Redirect URI ; tester la MFA auprès de l’IdP. Ni un parcours navigateur identique ni l’applicabilité du déploiement GPO Windows à macOS ne sont garantis.

Utiliser des noms de profil uniques, supprimer les anciennes connexions après un changement de gateway ou d’utilisateur et tester la distribution avec un utilisateur cible ordinaire. Les informations relatives aux versions se trouvent sous Mettre à jour Sophos Connect en toute sécurité.

SSL VPN avec Sophos Connect : Windows 10/11 ; client macOS 2.0 sur macOS 13+, et client 2.1 ou ultérieur sur macOS 14+. Linux, iOS et Android utilisent un client OpenVPN compatible.

Sous Current activities > Remote users, les utilisateurs distants connectés peuvent être filtrés par Connection date, Username, Source IP address et Leased IP address. La colonne Mode distingue trois états :

SSL VPN (remote access) : tunnel d’accès distant établi
User portal (clientless access) : connexion au portail d’un membre d’une stratégie SSL VPN clientless
User portal : connexion au portail sans cette appartenance

Une entrée de portail ne prouve donc pas l’existence d’un tunnel SSL VPN. Disconnect met fin à la session sélectionnée. Documenter l’utilisateur, les adresses, le mode et l’heure avant un test de support ou de validation.

Tester la configuration et circonscrire les erreurs

Test de validation

Effectuer un test complet avec un utilisateur pilote ordinaire et une destination interne précise :

Vérifier que l’utilisateur voit exactement la configuration SSL VPN attendue dans VPN Portal.
Tester le MFA avec un facteur correct, puis incorrect.
Importer .ovpn ou .pro et contrôler l’adresse attribuée.
Avec Split Tunnel, contrôler les routes vers LAN_Server et DNS_Internal.
Tester d’abord la destination interne par adresse IP, puis par nom d’hôte.
Accéder à un service autorisé et contrôler la Rule ID de pare-feu dans Log Viewer.
Tenter un accès interdit et confirmer le blocage.
Avec Full Tunnel, tester également l’accès Internet public, le DNS, la Web Policy et le SNAT IPv4.
Après une modification de stratégie ou de FQDN, se déconnecter, se reconnecter et répéter le même test.

Consigner pour chaque test l’heure, l’utilisateur et le groupe, la plateforme et la version du client, le réseau source, la destination et le service. Un test effectué uniquement avec un administrateur peut facilement masquer des erreurs de groupe, de MFA ou de stratégie.

Journaux selon la phase d’échec

Déterminer d’abord si l’erreur survient lors de l’accès au portail, de l’authentification, de l’établissement du tunnel ou seulement lors de l’accès à la destination :

VPN Portal : vpnportal.log
Authentification normale : access_server.log
Microsoft Entra SSO sous SFOS 22 : oauth_sso_vpn.log ; pour SFOS 23, utiliser les indications de journaux propres à la version dans l’article détaillé Entra ou Google correspondant.
Certificats SSL VPN propres à l’utilisateur : peruser_cert_sslvpn.log
Service SSL VPN : sslvpn.log
Connexions actives : openvpn-status*.log
Trafic vers la destination : journal du pare-feu, Rule ID et, si nécessaire, Packet Capture

Dans Packet Capture, Incoming prouve uniquement que le pare-feu a reçu le paquet. Si l’état est Forwarded mais qu’aucune réponse ne revient, contrôler la route de retour, le NAT, le système cible et son pare-feu local.

Pour le trafic TUN, les journaux SFOS affichent parfois l’adresse de l’interface TUN comme source et l’adresse attribuée au client comme destination. Cela ne signifie pas que les adresses ont été inversées. Pour interpréter l’entrée, il faut rapprocher l’utilisateur, l’adresse attribuée, le sens du trafic, la Rule ID et l’heure du test.

Services et journaux de Sophos Firewall associe les autres processus à leurs fichiers journaux.

Aucun utilisateur ne peut établir de tunnel : service et seuils de flood

Lorsque tous les utilisateurs sont affectés, commencez par des contrôles en lecture seule avant de modifier des stratégies, des seuils de flood ou des services. Notez l’heure du test, le protocole et le port SSL VPN configurés, les paramètres DoS actuels et la présence ou non d’au moins une stratégie SSL VPN.

Connectez-vous à la CLI, sélectionnez 5. Device management, puis 3. Advanced shell, et vérifiez l’état du service avec la commande documentée par Sophos :
```
service -S | grep sslvpn
```
Le service doit afficher Running. UNREGISTERED signifie qu’aucune stratégie SSL VPN n’est enregistrée ; vérifiez qu’il en existe au moins une. Si une stratégie existe mais que le service n’affiche toujours pas Running, corrélez sslvpn.log avec l’heure du test et analysez cette incohérence au lieu de redémarrer des services sans procédure documentée.
Sous Intrusion prevention > DoS & spoof protection > DoS settings, examinez les options et seuils de flood activés pour UDP, TCP et ICMP/ICMPv6. Pour le trafic du tunnel, utilisez le protocole SSL VPN configuré. SFOS abandonne le trafic SSL VPN et les requêtes ping lorsque le seuil correspondant est franchi ; l’échec d’un ping ne suffit pas à le prouver. Corrélez la tentative de connexion avec les preuves d’abandon avant de créer une exception.
Uniquement si le franchissement d’un seuil de flood est confirmé, consignez la configuration existante et créez sous DoS bypass rules la règle inbound temporaire la plus restrictive possible. L’exemple Sophos utilise l’adresse IP/le masque source pertinent (ou * seulement si cela est inévitable), l’adresse de la ressource réseau autorisée comme destination, le protocole réel TCP ou UDP, le port source Any et le port de destination SSL VPN configuré (8443 par défaut). Restreignez davantage la source et la destination lorsque le test le permet ; ne désactivez pas globalement la protection contre les floods.
Répétez à l’identique les tests horodatés de connexion et d’accès à la ressource autorisée. Si la règle de contournement n’explique pas l’abandon, supprimez-la immédiatement. Après le diagnostic, supprimez la règle temporaire ou faites approuver et documentez formellement l’exception restreinte. Rétablissez les valeurs consignées de tout seuil de flood modifié séparément, puis répétez les tests d’accès autorisé et bloqué.

La requête atteint le serveur, mais la réponse manque

Si la requête du client SSL VPN atteint manifestement la ressource interne autorisée, mais que la réponse ne revient pas au client, contrôler le chemin retour en deux étapes : d’abord de la ressource vers le pare-feu, puis du pare-feu vers l’adresse SSL VPN attribuée. Un tunnel affiché en vert ne permet pas d’isoler cette erreur.

Sur la ressource interne ou son routeur, vérifier que le chemin retour vers la plage d’adresses SSL VPN passe par Sophos Firewall. Une route de retour spécifique est plus transparente que le SNAT. N’utiliser le SNAT que de manière ciblée lorsque le retour ne peut pas être routé et que la modification de l’adresse source qui en résulte est acceptable.
Confirmer avec Packet Capture que la réponse atteint le pare-feu. L’adresse source, l’adresse de destination attribuée, le service et l’heure du test doivent correspondre à l’accès d’origine.
Sous Routing > SD-WAN routes, contrôler la Route Precedence actuelle et les routes SD-WAN trop larges. SSL VPN appartient à la catégorie static. Si sdwan_policyroute la précède, une route ayant la ressource interne ou Any comme source et Any comme destination et service peut détourner la réponse du tunnel.
Restreindre de préférence la route SD-WAN concernée afin que la plage d’adresses SSL VPN ne corresponde plus comme destination. Sophos indique aussi une exclusion de service pour le port et le protocole SSL VPN ; cette variante doit correspondre à la conception réelle des règles et du trafic.
Ne modifier la Route Precedence globale qu’après une analyse d’impact. Elle ne concerne pas uniquement cette connexion. Préparer l’ordre initial, l’accès de gestion et le rollback comme décrit dans Route Precedence sur Sophos Firewall.
Répéter l’accès et vérifier dans la capture l’arrivée de la réponse depuis la ressource ainsi que son transfert vers l’adresse attribuée. Se reconnecter ensuite et refaire le test avec la même application.

⚠️ Une règle large avec Any, une règle SNAT générale ou une modification globale de Route Precedence peut déplacer le problème visible et perturber d’autres chemins VPN, WAN ou de gestion. Arrêter si le chemin retour vers le pare-feu ou la route SD-WAN réellement correspondante n’est pas établi.

Le réseau domestique et le réseau interne de destination se chevauchent

Si le client externe utilise par exemple 192.168.1.0/24 et que la ressource interne autorisée se trouve elle aussi dans 192.168.1.0/24, le système d’exploitation considère généralement la destination comme locale. Le paquet n’atteint alors jamais le tunnel SSL VPN. La solution permanente et propre consiste à renuméroter l’un des deux réseaux.

Si ce changement n’est pas immédiatement possible, Sophos documente une solution de contournement DNAT strictement limitée. Il faut choisir une adresse de destination virtuelle libre qui ne chevauche aucun réseau local, interne, VPN, statique ou SD-WAN. Avec Split Tunnel, cette adresse doit être transmise au client comme Permitted network resource, puis une reconnexion est nécessaire. La règle DNAT utilise la plage de baux SSL VPN comme Original source, Original comme Translated source, l’adresse virtuelle comme Original destination et l’hôte interne réel comme Translated destination. Les services et la règle de pare-feu associée de VPN vers la zone de destination restent limités à l’accès réellement nécessaire.

L’utilisateur accède ensuite à l’adresse virtuelle ou à un nom DNS dédié qui pointe vers celle-ci. Log Viewer doit afficher les Firewall Rule ID et NAT Rule ID attendues ; un Packet Capture confirme la traduction et la route de retour. Il ne faut pas créer toute une plage de substitution si un seul hôte est nécessaire. S’arrêter si l’adresse virtuelle n’est pas incontestablement libre ou si une règle NAT trop large serait requise.

Erreurs courantes

Fichier .ovpn absent ou vide dans le VPN Portal : Résoudre un téléchargement OVPN absent ou vide distingue les erreurs de policy, User ID, certificat, stockage, firmware et HA. Les comptes invités ne sont pas pris en charge. Sophos Connect prend uniquement en charge les noms d’utilisateur ASCII ; le nom d’utilisateur et le domaine ne doivent pas dépasser 51 caractères au total.
Échec de la connexion : corréler access_server.log et vpnportal.log avec l’heure du test ; pour Entra sous SFOS 22, utiliser aussi oauth_sso_vpn.log, et sous SFOS 23 les indications de journaux OIDC propres à la version dans l’article détaillé correspondant. Vérifier le même serveur IdP pour le portail et SSL VPN, les Redirect URIs et la chaîne de certificats complète.
Le tunnel est établi, mais les destinations internes sont indisponibles : contrôler la route sur l’endpoint, les Permitted Resources avec Split Tunnel, la règle de pare-feu, la route de retour, le pare-feu de destination et un éventuel chevauchement avec le réseau domestique local.
L’adresse IP fonctionne, mais pas le nom d’hôte : contrôler le serveur DNS, le domaine de recherche, la route Split Tunnel, la règle de pare-feu DNS, le DoH local ou le DNS de l’endpoint et, le cas échéant, Device Access pour DNS.
Seuls certains utilisateurs sont concernés : comparer l’appartenance au groupe, l’affectation de stratégie, le MFA, l’adresse IP statique, Simultaneous logins et le profil chargé.
Seuls les anciens clients sont concernés : importer un fichier .ovpn à jour après une modification globale. Pour une modification limitée à la stratégie ou au FQDN, se reconnecter d’abord et contrôler les routes chargées.
Full Tunnel n’offre aucun accès Internet : contrôler la règle de VPN vers WAN, le SNAT IPv4, le DNS et les stratégies web et de sécurité appliquées.
Les transferts volumineux se bloquent : si les petites requêtes fonctionnent, contrôler MTU et MSS sur le chemin réel. Suivre la procédure MTU et MSS pour les problèmes VPN.
La connexion se termine après une période prolongée : comparer les heures de début et de déconnexion avec Idle Timeout, Disconnect idle clients et Key lifetime. Contrôler l’adresse IP statique et Simultaneous logins, utiliser si nécessaire une attribution dynamique pour un utilisateur pilote et analyser sslvpn.log ainsi que openvpn-status*.log à l’heure du test.
Aucun utilisateur ne peut établir de tunnel : en plus de Device Access et de la vérification de l’accessibilité du port SSL VPN, rechercher une règle DNAT générale avec Original destination: Any et Services: Any ou le port SSL VPN, qui intercepterait la connexion en premier.
Conflit entre WAF, le portail ou SSL VPN : comparer l’adresse IP WAN, le port et le protocole de tous les services locaux et règles WAF. Une combinaison partagée peut exposer le portail plus largement ou désactiver la sécurité de connexion.

En exploitation, contrôler régulièrement les groupes, le MFA, les affectations d’adresses IP statiques, l’expiration des certificats, la plage d’attribution, Device Access, les règles de pare-feu, la distribution des profils et les journaux. Tester d’abord les nouvelles versions de SFOS et Sophos Connect avec un utilisateur pilote, une destination autorisée et une destination bloquée.