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.

Pour le SSO sous Windows avec Sophos Connect 2.4 ou une version ultérieure, distinguer le firmware et le fournisseur : sous SFOS 22, suivre la procédure Entra ID liée ci-dessus ; SFOS 23 propose OpenID Connect (OIDC) avec un fournisseur d’identité (IdP) pris en charge. Entra ID reste une option valable. La configuration Google Workspace OIDC décrit l’autre fournisseur couvert ici et ses limites ; cela ne garantit pas la prise en charge de n’importe quel fournisseur OIDC, plateforme cliente ou build de firmware.

Pour un profil importé directement, sélectionner également le serveur IdP prévu dans Authentication > Services avant de télécharger la configuration. Avec SSL VPN direct, VPN Portal et SSL VPN doivent utiliser le même serveur. Avec IPsec direct, le tunnel peut utiliser le même serveur que VPN Portal ou un autre ; cela ne rend pas les fournisseurs librement interchangeables. L’extension OIDC pour Windows n’élargit pas la prise en charge d’Entra ID SSO sur macOS décrite plus bas.

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

1. Activer IPsec remote access.
2. 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.
3. 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.
4. Définir Authentication type sur Preshared key ou Digital certificate.
5. 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.

Dans Authentication > Groups, vérifier le réglage effectif IPsec remote access et l’ordre des groupes. Tant que Remote Access IPsec n’est pas configuré, il est désactivé par défaut pour tous les groupes. Après la configuration, les groupes AD importés et les groupes migrés restent désactivés par défaut ; les nouveaux groupes locaux sont en revanche activés par défaut. Si plusieurs groupes s’appliquent, la policy du groupe placé le plus haut l’emporte. Les policies individuelles d’utilisateur sont en principe prioritaires : un utilisateur peut par exemple être explicitement autorisé malgré la désactivation du groupe. L’exception décisive : si IPsec Remote Access est explicitement activé pour un groupe, cet accès ne peut pas être bloqué en désactivant individuellement l’un de ses membres. Lors du retrait des accès d’un utilisateur, vérifier donc son affectation effective à la Main-group, l’ordre des groupes et toutes les autorisations accordées au niveau de l’utilisateur ou des groupes, puis retirer l’autorisation effective plutôt que de se fier au commutateur de l’utilisateur. Selon Sophos, la désactivation d’un groupe déconnecte ses sessions actives et empêche leur rétablissement ; les autorisations individuelles doivent alors être vérifiées séparément. Avec un utilisateur pilote standard, contrôler l’authentification effective ainsi que les destinations autorisées et bloquées. Lors du retrait des accès, vérifier les sessions actives dans Current activities > IPsec connections, utiliser si nécessaire Disconnect de manière ciblée, puis confirmer que l’utilisateur ne peut plus s’authentifier ni accéder aux destinations protégées. Ces vérifications sont des étapes de validation, et non des effets démontrés ici sur un appareil. 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.

Si le pare-feu se trouve derrière un routeur, conservez d’abord une copie sécurisée de la .scx exportée comme profil source. Selon la FAQ Sophos, modifiez manuellement l’adresse de passerelle dans la .scx pour utiliser l’adresse IP WAN du routeur. Distribuez et réimportez le profil corrigé de manière contrôlée, puis testez le tunnel et le trafic autorisé depuis un réseau externe. Les redirections IKE/NAT-T restent nécessaires. À l’inverse, gateway dans .pro désigne le VPN Portal et ne corrige pas automatiquement l’extrémité du tunnel dans .scx ; aucune clé de schéma non vérifiée n’est supposée ici.

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 Any inutilement large ;
• During scheduled time: All the time ou une plage horaire justifiée ;
• Destination zones: la zone réellement requise, par exemple LAN ou DMZ ;
• 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 WAN utilisé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 VPN que si le firewall lui-même sert de résolveur DNS ;
• n’autoriser Ping/Ping6 depuis VPN que 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.

Pour le SSO Microsoft Entra ID avec Sophos Connect pour macOS à partir de la version 2.1, inclure également dans les tests de validation la connexion dans le navigateur ouvert par le client et le retour au client. Le processus de connexion macOS avec choix du navigateur et solution de repli explique les étapes ; vérifier ensuite l’état du tunnel, l’adresse IP du VPN, le DNS et l’accès, sans affaiblir les contrôles Conditional Access, MFA ou de certificat. Si un fichier .pro adapté est nécessaire à cette fin, utiliser la syntaxe exacte des champs et les valeurs autorisées de sso_auth_browser_type indiquées dans Sophos Connect Provisioning.

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, le fichier .pro doit être adapté et redistribué. Si les deux restent inchangés, le mécanisme de provisioning configuré peut récupérer à nouveau la configuration VPN et les modifications ultérieures. En revanche, avec un fichier .scx importé manuellement, après toute modification des General ou Advanced Settings, exporter à nouveau la connexion actuelle via Export connection, la distribuer par un canal sécurisé et la réimporter dans le client. Update policy ne remplace pas cette distribution manuelle ni la réimportation ; son utilisation documentée concerne le mécanisme de provisioning, en particulier les modifications du port SSL VPN ou du protocole. Une mise à jour du logiciel client n’actualise pas automatiquement la policy du pare-feu ni un profil obsolète ; les profils existants restent en principe utilisables après une simple mise à jour de la version de Sophos Connect. Conserver en sécurité le profil dont le bon fonctionnement est connu et les valeurs de pare-feu correspondantes pour permettre un retour arrière contrôlé. Avant une distribution à grande échelle, vérifier avec un utilisateur pilote standard la version du profil et la passerelle du tunnel, 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 du pare-feu et le profil dont le bon fonctionnement est connu, puis répéter les mêmes vérifications.

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. Pour le provisioning SSO, VPN portal authentication methods, VPN (IPsec/dial-in/L2TP/PPTP) authentication methods et SSL VPN authentication methods dans Authentication > Services doivent utiliser le même serveur IdP configuré : Entra ID sous SFOS 22, ou un IdP OIDC pris en charge sous SFOS 23 dans le périmètre Windows défini ci-dessus. gateway doit correspondre au FQDN ou à l’adresse IPv4 du firewall indiqués dans la section Redirect URI de ce serveur configuré dans Authentication > Servers. Il s’agit uniquement de l’hôte, et non de l’URI de callback complète avec schéma, port et chemin ; renseigner séparément le port du VPN Portal dans vpn_portal_port. Les limites propres au fournisseur restent applicables : pour Google Workspace, utiliser le FQDN valide exigé par le guide détaillé, et non une adresse IP. Comparer les affectations de serveur, l’hôte et le port du portail avant la distribution. En cas d’erreur SSO, suivre la procédure adaptée au firmware et au fournisseur dans l’article Entra ou Google lié ci-dessus ; ne pas généraliser les diagnostics Entra aux autres fournisseurs OIDC.

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 :

1. La connexion et MFA fonctionnent, et le client reçoit l’adresse prévue du pool ou de RADIUS.
2. 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.
3. Les FQDN internes et, si un suffixe DNS est configuré, les noms courts sont correctement résolus.
4. Les destinations autorisées fonctionnent, tandis que les autres restent bloquées.
5. Log Viewer affiche des correspondances avec la règle firewall prévue.
6. 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.
7. La reconnexion fonctionne après un délai d’inactivité, un changement de réseau et un redémarrage du terminal.
8. 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.

Contrôles complémentaires de déploiement et de migration

Certificats, ID et Advanced settings

Si le certificat RSA nécessaire manque, sélectionner Generate locally-signed certificate dans Certificates > Certificates > Add, ou charger un certificat existant avec Upload certificate. Renseigner les détails du certificat et Subject Name ; dans Subject Alternative Names, ajouter le nom DNS ou l’adresse IP prévue avec +. Vérifier ensuite les Certificate IDs et la chaîne de confiance commune comme indiqué ci-dessus. Remote ID ne doit pas être identique à Local ID. Enregistrer les General et Advanced settings avec Apply avant d’utiliser Export connection.

Selon Sophos, les identifiants enregistrés sont protégés par les services de trousseau du terminal ; cela ne remplace ni la protection du poste ni l’autorisation prévue par votre politique de sécurité. Prompt users for 2FA token nécessite une MFA réellement configurée pour Remote Access IPsec dans Authentication > Multi-factor authentication ou auprès du fournisseur OTP. Si le champ distinct est désactivé, ajouter l’OTP directement au mot de passe : passwordotp. Si des utilisateurs ont besoin de modes Split/Full Tunnel différents, utiliser des politiques SSL VPN Remote Access distinctes plutôt que distribuer des profils IPsec contradictoires.

Distribuer le client et retrouver les options de connexion

Les administrateurs téléchargent le client dans Remote access VPN > IPsec ou SSL VPN > Download client. Les utilisateurs trouvent Download for Windows et Download for macOS dans VPN portal > VPN > Sophos Connect client. Actualiser la version proposée par le firewall dans Backup & Firmware > Pattern updates ; déployer séparément les mises à jour des postes installés selon le runbook de mise à jour lié. Logs sur la page IPsec ouvre les journaux ; IPsec profiles mène aux paramètres IKE.

Le provisioning avec .pro est également documenté sur macOS avec Sophos Connect 2.1 ou ultérieur ; SSL VPN avec import direct de .ovpn est disponible à partir du client macOS 2.0. La distribution par GPO reste une procédure Windows. Lors d’une migration depuis un client tiers, les configurations existantes peuvent être importables ; pour IPsec, préférer un .scx fraîchement exporté ou un .pro actuel afin d’inclure les Advanced settings. Suivre le processus macOS.

Si Remember username and password déclenche une connexion automatique par mot de passe et masque le choix SSO, sélectionner Edit connection > Clear credentials dans le client. Les options réapparaissent à la connexion suivante ; cela ne modifie pas les autorisations du firewall.

Diagnostiquer le SSO et la déconnexion différée

Un choix SSO grisé dans le client Windows 2.4+ ou macOS 2.1+ peut résulter de l’absence de sso_api_port et sso_api_domain dans .scx ou .ovpn. Pour Entra ID, affecter d’abord le serveur dans Authentication > Services, puis exporter ou télécharger une nouvelle configuration et utiliser la méthode d’import appropriée. Ne pas deviner les valeurs ni les copier d’un autre tenant ; ne pas appliquer ce diagnostic Entra à Google Workspace sans vérification.

Si Entra Conditional Access échoue dans le navigateur intégré sur macOS 2.1+, terminer l’authentification dans le navigateur système ouvert par Sophos Connect, puis revenir au client. Si le client signale un appareil non conforme, effectuer les actions de conformité requises ou contacter l’IT. Réimporter un profil ne corrige pas un défaut de conformité ; ne pas contourner Conditional Access.

Après l’arrêt de l’interface WAN associée, les sessions Remote Access IPsec peuvent n’apparaître déconnectées qu’à l’expiration du délai d’inactivité ou du timeout DPD. Un tunnel encore affiché ne prouve donc pas la connectivité. Vérifier l’état de l’interface et les journaux avec l’état de la session ; utiliser Disconnect pour terminer une session précise, sans supposer que l’arrêt de l’interface déconnecte immédiatement les utilisateurs.

Limites SSL VPN et appareils mobiles

Avec .pro, .scx est récupéré comme configuration IPsec commune, tandis que .ovpn correspond aux politiques SSL VPN autorisées pour l’utilisateur ; télécharger un profil ne donne pas l’autorisation d’établir le tunnel. Les profils SSL sont disponibles dans VPN portal > VPN > VPN configuration > SSL VPN configuration. Les changements de port, de passerelle, de certificat serveur ou de protocole SSL VPN peuvent nécessiter une nouvelle connexion au client ; utiliser également Update policy pour les changements de port/protocole dans le processus provisionné. Lors du contrôle d’un .ovpn vide, noter que SSL VPN utilise par défaut ApplianceCertificate avec Default CA.

Un déploiement SSL VPN parallèle présente d’autres erreurs : depuis SFOS 20.0 MR1, l’ancien client SSL VPN legacy ne fonctionne plus ; migrer vers Sophos Connect ou une architecture IPsec planifiée. La migration de 18.5.x ou antérieur vers 19.5 ou ultérieur convertit l’ancienne plage d’adresses SSL en sous-réseau. Un objet IP host géré manuellement peut alors ne plus correspondre. Utiliser les hôtes système dynamiques ##ALL_SSLVPN_RW et ##ALL_SSLVPN_RW6 dans les règles concernées. Un .ovpn de 0 octet exige de vérifier le certificat et la Signing CA ; seulement après confirmation de la cause, renouveler le certificat concerné sous contrôle des changements, puis télécharger/importer de nouveau .ovpn. Pour Login failed. Wrong fingerprint of certificate. après changement de méthode de connexion ou de domaine, importer un .pro ou .ovpn distinct plutôt que désactiver la validation des certificats. Détails dans le runbook SSL VPN.

iOS peut télécharger le profil IPsec dans VPN portal > VPN > VPN configuration > IPsec VPN profile. Ce n’est pas un profil Sophos Connect de bureau pour appareils mobiles. La matrice du fabricant contient une attribution OpenVPN contradictoire dans la ligne IPsec ; elle ne permet pas d’établir une procédure IPsec sûre avec OpenVPN Connect. Pour SSL VPN mobile, utiliser .ovpn avec OpenVPN Connect ; pour IPsec mobile, vérifier avant le déploiement le client et le type de profil explicitement compatibles. Les contrôles de validation et de diagnostic décrits ici n’ont pas été exécutés sur une appliance ou un terminal.

FAQ