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.

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 :

SSL server certificate dans les paramètres globaux SSL VPN authentifie le serveur du tunnel.
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é. Avec 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.

Pour IPv4, SFOS autorise ici une taille de pool maximale de /24 ; les plages plus petites telles que /25 ne peuvent pas être sélectionnées. L’accès se limite avec la stratégie et les règles de pare-feu, pas avec un pool artificiellement petit. 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, autoriser plutôt 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.

Créer la stratégie SSL VPN

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

Remote access VPN > SSL VPN

L’assistant affiche les paramètres globaux pour contrôle, mais ne permet pas de les modifier. Il crée la stratégie, configure l’authentification choisie et Device Access pour VPN Portal et SSL VPN, puis crée la règle de pare-feu. Dans un environnement existant, Configure manually est généralement 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.
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.

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.

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.

Avec Microsoft Entra ID, sélectionner le même serveur Entra pour VPN Portal et SSL VPN. La configuration complète est documentée sous Microsoft Entra ID SSO pour Sophos Connect.

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

Avec un fichier .ovpn importé manuellement, les modifications des paramètres globaux qui affectent le profil doivent être téléchargées et importées à nouveau. Cela concerne notamment le protocole, le port, l’interface, le certificat serveur et d’autres valeurs de la configuration SSL VPN globale. Une mise à jour de Sophos Connect ne remplace pas un profil obsolète.

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. Ces modifications n’exigent pas un nouveau téléchargement du fichier .ovpn.

Un fichier de provisioning .pro est uniquement pris en charge sous Windows 10 et 11. Il télécharge les configurations IPsec et SSL VPN disponibles pour l’utilisateur et récupère automatiquement les modifications ultérieures. Si la gateway de provisioning ou le port de VPN Portal change, adapter et redistribuer le fichier .pro. Lors du premier provisioning, 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.

Après l’activation ou la modification de Microsoft Entra ID SSO, le client doit utiliser une configuration actuelle. Entra SSO dans Sophos Connect est pris en charge sous Windows à partir de la version 2.4 du client.

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

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 : oauth_sso_vpn.log
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.

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

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, vpnportal.log ou oauth_sso_vpn.log avec l’heure du test. Avec Entra, vérifier que le même serveur est configuré pour le portail et SSL VPN et que la chaîne de certificats est 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.