Configurer Sophos Connect sur Sophos Firewall
Sous SFOS 22, Sophos Connect pour IPsec Remote Access se configure dans Remote access VPN > IPsec. Le tunnel ne suffit pas à autoriser l’accès : l’authentification, l’adressage des clients, le DNS, les règles firewall et le profil distribué doivent fonctionner de concert.
Cet article se limite volontairement à la configuration côté firewall. L’installation et l’importation font l’objet de guides distincts pour Windows et macOS. Pour SSL VPN, consulter Configurer Sophos Firewall SSL VPN Remote Access ; si le choix de l’architecture reste ouvert, voir Sophos Connect ou SSL VPN.
Avant de commencer
Un déploiement maîtrisé nécessite :
- un accès administrateur à WebAdmin et une adresse WAN joignable ;
- des utilisateurs ou groupes provenant d’une source prise en charge par Sophos Connect, par exemple la base locale, Active Directory, RADIUS ou Microsoft Entra ID, ainsi qu’une stratégie MFA adaptée ;
- un pool de clients privé disponible, les réseaux internes de destination et les seuls services réellement nécessaires ;
- des serveurs DNS capables de résoudre les noms internes prévus et, si nécessaire, un suffixe DNS ;
- un profil IPsec IKEv1 et soit une clé prépartagée, soit des certificats RSA appropriés ;
- un accès de test externe, par exemple via un point d’accès mobile. SFOS ne prend pas en charge IPsec Remote Access depuis la zone LAN.
Avant une mise à niveau vers SFOS 22.0 MR1 ou une version ultérieure, vérifier d’abord si Legacy Remote Access IPsec doit être migré.
Commencer par affecter les services d’authentification
Dans Authentication > Services, les serveurs requis doivent apparaître aux bons endroits dans Selected authentication server :
- VPN portal authentication methods pour le VPN Portal et le provisioning ;
- VPN (IPsec/dial-in/L2TP/PPTP) authentication methods pour la connexion au tunnel IPsec.
Une configuration courante associe Local au serveur d’annuaire, RADIUS ou Entra ID défini dans Authentication > Servers. Tester cette affectation avant l’exportation. Avec Microsoft Entra ID SSO, le serveur Entra ID doit déjà être sélectionné ici avant le téléchargement du fichier de configuration ; sinon, les valeurs SSO manqueront dans le fichier .scx. La procédure complète est décrite dans Microsoft Entra ID SSO pour VPN, et la configuration OTP dans Configurer MFA sur Sophos Firewall.
Définir les adresses, les destinations et la procédure de retour
Pour éviter tout conflit d’adresses, le pool VPN ne doit chevaucher ni LAN, ni WLAN, ni VLAN, ni VPN site à site, ni réseaux domestiques courants. SFOS exige en outre que la plage appartienne à un sous-réseau d’au moins /24 et ne soit pas utilisée simultanément pour SSL VPN, L2TP ou PPTP. On peut, par exemple, utiliser 10.250.10.10 à 10.250.10.200 dans 10.250.10.0/24.
Avant toute modification, documenter la configuration IPsec actuelle, les certificats et ID sélectionnés, l’ordre des règles ainsi que les versions .scx/.pro déjà distribuées. Conserver l’ancien profil en lieu sûr. En cas d’échec, il sera alors possible de rétablir séparément les valeurs et les règles sans supprimer les utilisateurs, certificats ou autres configurations VPN existants. En revanche, l’option Reset au bas de la page IPsec rétablit les paramètres d’usine de la configuration Remote Access IPsec ; il ne s’agit pas d’une procédure de retour normale.
Configurer intégralement IPsec Remote Access
Les anciennes interfaces et la capture d’écran existante affichent encore VPN > Sophos Connect Client. Sous SFOS 22, le chemin est Remote access VPN > IPsec.

General settings
- Activer IPsec remote access.
- Dans Interface, sélectionner le port WAN qui servira de terminaison au tunnel. SFOS ne permet qu’une seule interface WAN dans cette configuration Remote Access ; plusieurs passerelles de provisioning ne modifient pas cette association du tunnel.
- Dans IPsec profile, sélectionner un profil IKEv1. Il n’apparaît que si Dead Peer Detection est désactivé ou réglé sur Disconnect. Les algorithmes des phases 1 et 2, DH/PFS et les durées de vie doivent respecter la politique de sécurité. Les algorithmes robustes et PFS sont de bonnes pratiques ; les conditions IKEv1 et DPD indiquées ci-dessus sont, quant à elles, imposées par SFOS.
- Définir Authentication type sur Preshared key ou Digital certificate.
- Renseigner Local ID, Remote ID et Allowed users and groups.
La clé PSK est incluse dans la configuration exportée. Elle doit être aléatoire et protégée et, en cas de suspicion, être remplacée en même temps que tous les profils concernés. MFA renforce la protection de la connexion utilisateur, mais ne remplace pas cette clé de tunnel.
Sous SFOS 22, Digital certificate est soumis à des limites précises :
- IPsec utilise des certificats RSA, et non ECDSA ;
- les Local et Remote Certificate nécessitent une Certificate ID ;
- External certificate ne doit pas être sélectionné ;
- les Local et Remote Certificate doivent appartenir à la même chaîne de confiance. Utiliser soit des certificats générés localement, soit des certificats émis par la même CA tierce, puis charger la Signing CA correspondante sur le firewall.
Sophos recommande une Local ID pour identifier le firewall et une Remote ID différente pour les clients. Les types admis sont DNS, IP Address, Email et, pour les certificats, DER ASN1 DN [X509]. Dans ce dernier cas, le firewall reprend le Distinguished Name du certificat. Les ID n’ont pas besoin d’être résolues publiquement, mais le firewall et le profil exporté doivent attendre les mêmes valeurs.
Autoriser correctement les utilisateurs et les groupes
Dans Allowed users and groups, n’ajouter que les comptes prévus. Pour un utilisateur d’annuaire, IPsec Remote Access tient compte du Main group. Le groupe AD autorisé doit donc être son groupe principal ; dans le cas contraire, autoriser explicitement l’utilisateur plutôt que d’ouvrir l’accès à un groupe étendu.
Vérifier également dans Authentication > Groups que IPsec remote access est activé pour ce groupe. L’option est désactivée par défaut pour les groupes AD importés et les groupes migrés, et activée par défaut pour les nouveaux groupes locaux. Si plusieurs groupes s’appliquent, la policy du groupe placé le plus haut l’emporte ; une policy individuelle d’utilisateur reste prioritaire. La désactivation d’IPsec Remote Access pour un groupe entraîne la déconnexion de ses sessions actives par SFOS et empêche leur rétablissement. Pour en savoir plus sur l’ordre des groupes, voir Connecter Active Directory à Sophos Firewall.
Avant sa première connexion Sophos Connect classique, un utilisateur AD doit généralement se connecter à un autre Authentication Client, tel que le User Portal. Le provisioning peut créer le compte lors de la première connexion et l’affecter selon le mapping du serveur. Les Guest users et guest groups ne sont pas autorisés pour Remote Access.
Client information et Idle time
Renseigner délibérément tous les champs de Client information :
- Name: un nom d’affichage court et unique, tel que
remote-access-ipsec; - Assign IP from: le début et la fin du pool privé prévu ;
- Allow leasing IP address from RADIUS server for L2TP, PPTP, and IPsec remote access: n’activer que si RADIUS attribue les adresses. Si RADIUS ne fournit aucune adresse, SFOS utilise d’abord l’adresse statique configurée pour l’utilisateur, puis, à défaut, une adresse de Assign IP from ;
- DNS server 1 et DNS server 2: des résolveurs faisant autorité pour les zones requises ou leur transmettant correctement les requêtes.
Les résolveurs publics ne sont pas mauvais par principe, mais ils ne résolvent généralement pas les zones d’entreprise privées sans publication ou transfert approprié. Pour les ressources internes, tester donc le véritable chemin DNS faisant autorité ou assurant le transfert.
Dans Idle time, il est possible d’activer Disconnect when tunnel is idle. Idle session time interval s’exprime en secondes. La valeur relève d’un choix opérationnel : un délai court réduit les sessions abandonnées, mais peut perturber les flux de travail et les reconnexions MFA. Après une déconnexion pour inactivité, Sophos Connect tente de rétablir la connexion en arrière-plan ; en cas d’échec, sélectionner d’abord Disconnect, puis Connect dans le client.
Advanced settings
Ces valeurs sont enregistrées dans .scx, mais pas dans .tgb :
- Use as default gateway: activé pour Full Tunnel, désactivé pour Split Tunnel. Ce choix s’applique à tous les utilisateurs répertoriés dans Allowed users and groups ; il est impossible de définir des comportements différents dans une même configuration IPsec.
- Permitted network resources (IPv4): réseaux et hôtes internes du Split Tunnel. N’ajouter que les ressources auxquelles les utilisateurs doivent accéder par le tunnel.
- Send Security Heartbeat through tunnel: transmettre par le tunnel le Heartbeat d’un Sophos Endpoint existant.
- Allow users to save username and password: n’autoriser cette option que si la protection des appareils et les exigences MFA le permettent. Pour Connect tunnel automatically, Sophos recommande d’enregistrer les identifiants.
- Prompt users for 2FA token: afficher un champ OTP distinct. Le firewall transmet néanmoins
passwordotp; les méthodes MFA de type challenge ne sont pas prises en charge. SCCLI ne fonctionne pas avec cette option. - Run AD logon script after connecting: exécuter le script de connexion AD après l’établissement du tunnel.
- Connect tunnel automatically: établir automatiquement la connexion après l’ouverture de session sur le terminal.
- Hostname or DNS suffix to monitor: saisir un nom d’hôte résolu uniquement en interne ou un suffixe interne. Sophos Connect s’en sert pour évaluer la connexion automatique ; l’hôte surveillé doit être autorisé à répondre aux sondes ICMP.
- Assign client DNS suffix: ajouter un suffixe tel que
firma.exampleà la carte réseau du terminal afin que les noms d’hôtes courts soient résolus comme des FQDN.
Avec Split Tunnel, SFOS crée des SA ESP distinctes pour les sous-réseaux autorisés et, en cas d’inactivité, ne supprime que la Child SA concernée. Avec Full Tunnel, il existe une seule SA ESP, supprimée après l’intervalle d’inactivité si aucun trafic ne circule.
Vérifier l’accessibilité en amont du firewall
Si Sophos Firewall se trouve derrière un routeur ou un autre équipement NAT, celui-ci doit traduire l’adresse publique vers l’interface WAN sélectionnée du firewall. Pour NAT-T, autoriser et rediriger UDP 500 et UDP 4500. En l’absence de NAT sur le trajet, le trafic ESP utilise le protocole IP 50 ; l’équipement en amont doit alors également le laisser passer. Lorsque SFOS détecte le NAT, NAT-T encapsule les paquets IKE et ESP suivants dans UDP 4500.
Un test de port TCP/UDP classique ne suffit donc pas à valider l’intégralité du trajet IPsec. Le NAT opérateur, le double NAT ou un réseau invité restrictif peuvent également empêcher l’établissement de la connexion. Si l’adresse publique est directement affectée à SFOS, aucune règle DNAT en amont n’est nécessaire.
Règles firewall et Device Access
Accès aux destinations internes
Dans Rules and policies > Firewall rules, créer une règle IPv4 ciblée :

- Rule name: un nom unique, par exemple
VPN-SophosConnect-to-ERP; - Rule position: au-dessus d’une règle Drop plus générale ou d’une règle Accept contradictoire ;
- Action: Accept ;
- Log firewall traffic: activer pour la recette et l’exploitation ;
- Source zones:
VPN; - Source networks and devices: le pool de clients IPsec ou un objet IP host approprié, et non un
Anyinutilement large ; - During scheduled time:
All the timeou une plage horaire justifiée ; - Destination zones: la zone réellement requise, par exemple
LANouDMZ; - Destination networks: uniquement les serveurs ou réseaux autorisés ;
- Services: uniquement les protocoles et ports nécessaires ;
- Match known users et Users or groups: éventuellement, une condition d’identité supplémentaire si elle convient au modèle d’authentification.
SFOS évalue les règles de haut en bas et s’arrête à la première correspondance. Après l’enregistrement, contrôler leur position effective ; des règles créées automatiquement ou ajoutées ultérieurement tout en haut peuvent modifier l’ordre. Web, Application Control, IPS, Heartbeat et les autres policies de sécurité ne sont pas imposés de manière générale par SFOS au trafic VPN. Les sélectionner selon le niveau de protection requis et les tester avec les applications.
Accès Internet en Full Tunnel
Avec Use as default gateway, une règle supplémentaire est nécessaire pour le trafic de VPN vers WAN :

Cette règle utilise elle aussi le pool de clients comme réseau source, les services appropriés, la journalisation et les policies Web, Application Control ou IPS souhaitées. Le pool de clients doit également être couvert par une règle SNAT/Masquerading adéquate ; une règle NAT existante peut déjà remplir ce rôle. Une règle NAT liée est possible, mais pas obligatoire. Les règles NAT sont elles aussi évaluées dans l’ordre : une règle antérieure et plus large l’emporte. Un Full Tunnel sans politiques NAT et de sécurité cohérentes aboutit donc souvent à un tunnel vert sans accès Internet, ou à un trafic involontairement non filtré.
Local Service ACL
Les règles firewall régissent le trafic transféré, et non les services locaux du firewall. Dans Administration > Device access :
- autoriser IPsec depuis la zone
WANutilisée ; - n’autoriser VPN portal que depuis les zones nécessitant le téléchargement ou le provisioning ; Sophos recommande de n’ouvrir l’accès WAN que temporairement ;
- n’autoriser DNS depuis
VPNque si le firewall lui-même sert de résolveur DNS ; - n’autoriser Ping/Ping6 depuis
VPNque si le firewall lui-même doit servir de cible de test.
Lorsqu’une zone entière serait trop large, une Local service ACL exception rule permet de limiter l’accès à certains hôtes ou réseaux sources. Pour plus de détails, consulter Device Access et Local Service ACL.
Exporter ou provisionner le profil
Export connection crée une archive contenant .scx et .tgb. Pour Sophos Connect, .scx constitue le format standard et contient les General et Advanced Settings. .tgb est destiné aux clients tiers compatibles et ne contient que les General Settings. Après toute modification des General ou Advanced Settings, redistribuer la configuration ; si seuls les Advanced Settings changent, seul .scx est concerné.
Sous Windows, avec Sophos Connect 2.1 ou une version ultérieure, un fichier .pro peut télécharger les configurations IPsec et SSL VPN autorisées depuis le VPN Portal, puis récupérer automatiquement les modifications ultérieures. Provisioning Sophos Connect avec .pro et GPO décrit la structure JSON exacte, les multiples passerelles de portail, les champs MFA et la distribution par GPO.
Distinction importante pour le dépannage : dans .pro, gateway désigne le FQDN ou l’adresse IPv4 du firewall par lequel le client accède au VPN Portal et récupère les configurations. Ce n’est pas automatiquement la passerelle du tunnel IPsec. Le tunnel aboutit à l’Interface sélectionnée dans Remote access VPN > IPsec et enregistrée dans le fichier .scx téléchargé. Plusieurs passerelles dans .pro offrent donc plusieurs chemins de provisioning, mais pas de Multi-WAN pour cette configuration IPsec Remote Access unique.
Si gateway ou le port du VPN Portal change, adapter et redistribuer .pro. Si les deux restent inchangés, le provisioning peut récupérer de nouveau la configuration VPN. Pour un profil IPsec importé manuellement, l’utilisateur lance la récupération dans le client via Edit connection > Update policy ; une simple mise à jour du client ne met pas à jour la policy du firewall. En principe, les profils existants restent utilisables après une simple mise à jour de la version de Sophos Connect.
Si le provisioning charge d’anciennes valeurs ou ne récupère aucune configuration, vérifier successivement l’accessibilité et le certificat du VPN Portal, le port du portail, gateway, la connexion de l’utilisateur et MFA. Avec Entra ID SSO, gateway doit également correspondre à la Redirect URI enregistrée.
Les profils contiennent des informations sensibles et doivent être distribués par un canal protégé. Nommer sans ambiguïté les anciennes et nouvelles versions afin d’éviter que le helpdesk ou les utilisateurs ne reviennent par erreur à une version antérieure.
La distribution d’une nouvelle policy firewall ne doit pas être confondue avec la mise à jour du logiciel client. Le choix des versions, les groupes pilotes et la procédure de retour sont traités dans Mettre à jour Sophos Connect en toute sécurité.
Documenter le groupe VPN responsable de l’exploitation et la procédure de départ, la réinitialisation de MFA ainsi que le verrouillage et le déverrouillage des utilisateurs. La documentation d’exploitation doit également inclure la version du profil, la date de modification et le responsable, les exigences de logging permanent, y compris Sophos Fusion (anciennement Sophos Central) ou Syslog, ainsi qu’un nouvel examen des profils avant les mises à niveau de SFOS.
Recette avec un véritable client distant
Après l’importation, effectuer les tests avec un utilisateur cible standard depuis un réseau externe :
- La connexion et MFA fonctionnent, et le client reçoit l’adresse prévue du pool ou de RADIUS.
- La session apparaît dans Current activities > IPsec connections. La liste peut notamment être filtrée par Connection name, Username, Local subnet et Remote host/subnet ; Refresh actualise l’affichage et Disconnect met fin à une connexion donnée.
- Les FQDN internes et, si un suffixe DNS est configuré, les noms courts sont correctement résolus.
- Les destinations autorisées fonctionnent, tandis que les autres restent bloquées.
- Log Viewer affiche des correspondances avec la règle firewall prévue.
- Split Tunnel laisse le reste du trafic Internet en local ; Full Tunnel le fait passer par le firewall, la règle SNAT attendue et les policies de sécurité prévues.
- La reconnexion fonctionne après un délai d’inactivité, un changement de réseau et un redémarrage du terminal.
- Dans le client Sophos Connect, Events affiche la chronologie de l’importation, de la connexion et de l’établissement du tunnel. En cas d’erreur reproductible, générer un Support report dans le client et le conserver avec l’horodatage, l’utilisateur, la version du client et celle du profil avant de modifier les profils ou les certificats.
Pour analyser les règles, consulter Tester une règle firewall avec Log Viewer, Policy Test et Packet Capture. Pour une analyse approfondie du tunnel, poursuivre avec Dépannage IPsec VPN sur Sophos Firewall.
Dépannage ciblé
Échec de la connexion
Vérifier d’abord Authentication > Services, l’état du mot de passe et de MFA, les verrouillages et le serveur d’authentification indépendamment du VPN. Comparer ensuite le Main group, Allowed users and groups et l’option IPsec remote access du groupe. Sophos Connect n’accepte que les caractères ASCII dans les noms d’utilisateur ; les trémas et autres caractères UTF-8/UTF-16 peuvent empêcher la connexion.
Plutôt que de fonder le diagnostic sur un unique message IKE insuffisamment documenté, décomposer la procédure : la tentative atteint-elle l’authentification de l’utilisateur ? L’interface, le profil IPsec, le certificat ou le PSK ainsi que les Local/Remote ID correspondent-ils ? L’utilisateur est-il réellement autorisé via son Main group ? Les événements du client et les logs du firewall relevés au même moment fournissent une piste plus fiable.
Failed to validate certificate après un redémarrage
Si la première connexion fonctionne, mais que Failed to validate certificate apparaît après un redémarrage, les Local et Remote Certificate ne sont souvent pas signés par la même CA. Vérifier les Certificate IDs et la chaîne de confiance. Utiliser des certificats générés localement ou issus de la même CA tierce en chargeant sa Signing CA, ou choisir délibérément un PSK. Exporter et importer ensuite de nouveau .scx, puis refaire le test après un redémarrage.
Le tunnel est connecté, mais aucun trafic ne passe
Vérifier d’abord l’adresse attribuée et les routes du client, puis Permitted network resources, la position de la règle, les Source/Destination networks, les Services, le chemin retour et le DNS. Pour Full Tunnel, contrôler également la règle de VPN vers WAN et la règle SNAT réellement appliquée. Device access n’intervient que si le firewall lui-même est la destination, par exemple pour DNS ou ping.
La connexion s’interrompt environ toutes les quatre heures
Lors du rekeying IKEv1, une nouvelle demande OTP peut interrompre le tunnel. Sophos indique un intervalle de rekeying d’environ quatre heures pour le profil IPsec par défaut ; un profil personnalisé peut aller jusqu’à 24 heures. Corriger le délai d’expiration d’IPsec Remote Access après quatre heures explique le compromis de sécurité et sa mise en œuvre.
Les transferts volumineux se bloquent ou seuls certains réseaux externes échouent
Si la connexion, le DNS et les petits accès fonctionnent, mais que les transferts plus importants se bloquent, vérifier MTU et MSS. Si IPsec échoue uniquement dans les hôtels, les Wi-Fi invités ou les réseaux d’entreprise fortement filtrés, l’accès externe peut bloquer UDP 500/4500 ou ESP. SSL VPN ou une autre architecture Remote Access sera peut-être plus robuste pour ces utilisateurs.
Remote Access IPsec après un failover HA
L’erreur NC-175860, documentée dans les notes de version de SFOS 22, affecte Remote Access IPsec après un failover HA lorsque l’Appliance Certificate a été régénéré auparavant. Elle a été corrigée dans SFOS 22.0 MR2 Build 546 du 14 juillet 2026. Sophos ne fournit ni message de log spécifique, ni solution de contournement officielle.
Avant toute intervention, consigner le firmware et la build, le mode HA, les rôles et Last status change sur les deux appliances, l’heure du failover, l’Authentication Type, les Local/Remote Certificate avec leurs Certificate IDs et la version du profil. Ne pas régénérer l’Appliance Certificate sur la base d’une simple supposition. Sur une ancienne version affectée, vérifier le chemin de mise à niveau approuvé vers MR2 Build 546 ou une version ultérieure, puis tester un failover contrôlé et une reconnexion externe pendant une fenêtre de maintenance. Pour les bases de la topologie, voir Variantes de clusters HA Sophos Firewall ; pour la procédure de mise à niveau, voir Mise à jour du firmware SFOS.