Configurer le provisioning Sophos Connect avec .pro

Un fichier de provisionnement Sophos Connect avec l’extension .pro n’est pas un profil VPN complet. Il indique au client Windows quel portail VPN utiliser pour récupérer les configurations IPsec et SSL VPN. Après une connexion réussie au portail, Sophos Connect importe le fichier .scx et, si l’utilisateur est affecté à une politique VPN SSL, aussi le fichier .ovpn. Un profil visible ne signifie pas encore que l’authentification des tunnels ou l’accès aux destinations internes est autorisé.

Cette méthode est particulièrement pratique lorsque les profils doivent être distribués de manière centralisée et que les modifications ultérieures doivent être récupérées automatiquement. Le portail VPN fait alors partie du chemin d’authentification en production. Son accessibilité, son certificat, la MFA, l’attribution des utilisateurs et son durcissement sont donc aussi importants que la syntaxe JSON du fichier.

⚠️ Si des utilisateurs externes doivent effectuer le provisioning depuis le WAN, le portail VPN doit être accessible depuis le WAN. Cela augmente la surface d’attaque exposée publiquement. Avant le déploiement, prévoyez un certificat approuvé, la MFA, des ACL Local Service aussi restrictives que possible, des mécanismes de blocage des connexions testés et une solution de repli reposant sur un profil distribué manuellement.

Le provisioning en huit étapes

1. Configurez entièrement IPsec Remote Access ou SSL VPN sur le pare-feu et testez la configuration avec un fichier importé manuellement.
2. Publiez le portail VPN sous un FQDN couvert par un certificat approuvé.
3. Sous Administration > Device access, activez le portail VPN uniquement pour les zones requises. Pour restreindre l’accès à des réseaux sources spécifiques, il faut également une règle d’exception de service local appropriée.
4. Créez un fichier .pro minimal avec display_name, gateway et vpn_portal_port.
5. N’ajoutez la MFA, la connexion automatique et l’ordre des passerelles qu’une fois le processus correspondant clairement défini.
6. Importez d’abord le fichier manuellement avec un utilisateur pilote et testez IPsec et SSL VPN séparément.
7. Transmettez ensuite le fichier .pro approuvé au déploiement Windows administré et commencez par un petit groupe pilote.
8. Validez la connexion au portail, les profils importés, le tunnel, les destinations internes, les journaux, les mises à jour de profil et le retour arrière.

Quand utiliser un fichier .pro

Le provisioning convient bien aux terminaux Windows gérés qui utilisent Sophos Connect pour IPsec, SSL VPN ou les deux. Après la connexion au portail, le pare-feu fournit le profil IPsec à tous les utilisateurs. Cela ne signifie pas que chaque utilisateur peut authentifier le tunnel ou accéder aux destinations internes. Une configuration SSL VPN n’est importée que si l’utilisateur est membre d’une stratégie SSL VPN correspondante.

Lors du premier provisioning, SFOS peut créer automatiquement un utilisateur d’annuaire qui n’existe pas encore localement et l’affecter à un groupe selon le mappage du serveur d’authentification. L’utilisateur n’a donc pas besoin de se connecter auparavant au portail VPN ou au portail utilisateur. Cette création automatique ne remplace pas la vérification de l’ordre des groupes et de l’autorisation VPN réelle.

Les fichiers manuels .scx et .ovpn restent utiles si le VPN Portal ne doit pas être accessible publiquement, si les clients sont peu nombreux ou si le portail constitue une dépendance supplémentaire indésirable. .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.

Actualisation de l’observation datée : les notes de version Sophos listent Sophos Connect 2.1 pour macOS, publié le 6 octobre 2026, avec provisioning .pro, Entra ID SSO et prise en charge ARM native. L’observation du 24 septembre 2026 décrit la situation d’alors. Vérifiez la version du paquet réellement disponible ; sa publication ne prouve pas que votre portail le propose déjà ni qu’il a été testé sur un appareil précis.

La configuration VPN proprement dite reste traitée dans les guides dédiés : Configurer Sophos Connect IPsec sur le pare-feu et Configurer l’accès distant SSL VPN.

Prérequis et valeurs d’exemple

L’exemple suivant utilise le nom public du portail vpn.example.com et l’hôte de contrôle interne intranet.corp.example. Ces deux noms sont des valeurs d’exemple :

• vpn.example.com doit être remplacé par le véritable FQDN du portail VPN, correctement résolu depuis l’extérieur et l’intérieur. Le certificat du portail doit être valide pour ce nom et approuvé par les clients.
• intranet.corp.example ne doit être utilisé comme auto_connect_host que si l’hôte est disponible de manière stable et répond exclusivement depuis le réseau interne. Un hôte public ou peu fiable fausserait la détection du réseau.
• Le port 443 est le port par défaut du portail VPN. Si le pare-feu utilise un autre port, la même valeur doit figurer dans vpn_portal_port.

Avant de créer le fichier, les points suivants doivent au minimum avoir été testés avec succès :

• Le profil IPsec ou SSL VPN prévu fonctionne avec une importation manuelle.
• Le portail VPN est accessible par le FQDN prévu et utilise une chaîne de certificats complète.
• Les utilisateurs, groupes principaux, stratégie SSL VPN et méthodes d’authentification correspondent.
• Pour le provisioning SSO, le portail VPN, IPsec et SSL VPN utilisent le même serveur de fournisseur d’identité (IdP) configuré sous Authentication > Services : Microsoft Entra ID dans la documentation SFOS 22, ou un IdP OpenID Connect (OIDC) pris en charge sous SFOS 23.
• gateway correspond au FQDN ou à l’adresse IP du pare-feu configuré dans la section Redirect URI du serveur IdP. Saisissez uniquement cet hôte, pas l’URI de callback complète avec schéma, port et chemin ; définissez le port du portail séparément dans vpn_portal_port.
• La MFA et le test négatif avec un utilisateur non autorisé fonctionnent.

Pour publier le portail, consulter Device Access et Local Service ACL. Protection contre les attaques par force brute sur le portail VPN explique les échecs de connexion répétés et le durcissement d’un portail accessible depuis le WAN.

Choisir la version SSO et le fournisseur

Pour Windows avec Sophos Connect 2.4 ou ultérieur, SFOS 22 décrit Entra ID SSO ; SFOS 23 étend cette portée aux IdP OIDC pris en charge. Cela ne signifie ni la prise en charge de tous les fournisseurs OIDC ni une disponibilité prouvée dans un build de firmware donné. Utilisez la branche de version correspondante dans Entra ID VPN SSO ou la configuration Google Workspace OIDC pour SFOS 23. Google exige un FQDN public valide pour les redirections, pas une adresse IP. Ces guides décrivent la configuration du fournisseur, l’affectation des services et le dépannage.

Pour télécharger directement un .scx ou .ovpn sans .pro, sélectionnez d’abord l’IdP sous Authentication > Services, puis téléchargez le profil. SSL VPN doit utiliser le même IdP pour le portail et le tunnel ; IPsec direct peut utiliser le même IdP ou un autre. N’appliquez pas cette exception IPsec au provisioning.

Pour macOS 2.1 ou ultérieur, le guide client cite Entra ID SSO, pas une prise en charge OIDC générale. Les prérequis et le guide client sauvegardés diffèrent quant à la couverture macOS ; confirmez et testez séparément la combinaison firmware/client/VPN prévue. Le champ de navigateur macOS ci-dessous reste propre à Entra ; GPO, automatisation du dossier d’importation et scripts de connexion restent propres à Windows.

Créer le fichier de provisioning

Un fichier .pro est JSON. gateway est le seul champ requis. Le nom d’affichage et le port portail doivent néanmoins être définis explicitement de manière à ce que la configuration puisse être revue sans ambiguïté. Créez le fichier avec un éditeur de texte et enregistrez-le, par exemple, sous avanet-vpn.pro.

Profil minimal pour une passerelle

[
  {
    "display_name": "Avanet Remote Access",
    "gateway": "vpn.example.com",
    "vpn_portal_port": 443,
    "otp": false,
    "auto_connect_host": "",
    "can_save_credentials": false,
    "check_remote_availability": true,
    "run_logon_script": false
  }
]

display_name ne peut pas dépasser 60 caractères. Sans nom d’affichage, Sophos Connect affiche la valeur gateway. Lorsque can_save_credentials vaut true, l’utilisateur peut enregistrer son nom d’utilisateur et son mot de passe ; ce réglage n’est pas utilisé avec le SSO. L’autorisation d’enregistrer les identifiants est une décision de sécurité, pas un réglage de confort par défaut.

Les champs non spécifiés prennent les valeurs par défaut du fabricant. L’exemple les définit tous explicitement afin qu’aucune valeur implicite n’échappe à la revue :

Avec check_remote_availability, le client effectue un contrôle de disponibilité au démarrage de la connexion. run_logon_script s’applique uniquement à Sophos Connect pour Windows ; les valeurs autorisées sont true et false, avec false par défaut. Il exécute le script d’ouverture de session fourni par le contrôleur de domaine une fois le tunnel établi. Ce script reste désactivé jusqu’à ce qu’un test pilote en confirme la nécessité et le comportement.

L’ancienne syntaxe user_portal_port reste acceptée, mais elle désigne aujourd’hui aussi le port du portail VPN. vpn_portal_port est plus explicite pour les nouveaux fichiers.

Choisir le navigateur Entra ID SSO sous macOS

Le champ facultatif sso_auth_browser_type s’applique exclusivement à Microsoft Entra ID SSO avec Sophos Connect pour macOS 2.1 ou ultérieur. Ce n’est ni un réglage Windows ni une option générale de navigateur pour d’autres fournisseurs d’identité. Les valeurs autorisées s’écrivent littéralement :

• auto : valeur par défaut ; utilise le navigateur intégré et peut basculer vers le navigateur système si nécessaire.
• embedded : utilise le navigateur intégré à Sophos Connect.
• system : utilise le navigateur par défaut du système d’exploitation.

Si le champ est omis ou contient une valeur non valide, Sophos Connect utilise auto. Pour une configuration Entra adaptée sous macOS, cette propriété facultative peut être ajoutée à l’objet de connexion du fichier .pro :

"sso_auth_browser_type": "auto"

Il s’agit uniquement d’un fragment JSON, pas d’un fichier .pro complet. La propriété se place à côté de gateway dans l’objet existant ; les propriétés sont séparées par des virgules, sans virgule après la dernière. auto rend la valeur par défaut explicite pour la revue ; embedded ou system ne sont définis que pour un processus de navigateur choisi délibérément et vérifié lors d’un pilote. Sophos Connect sous macOS décrit l’importation et la connexion interactive ; la syntaxe du champ est décrite ici.

Planifier correctement la connexion automatique

auto_connect_host aide Sophos Connect à déterminer si le client se trouve déjà sur le réseau interne. Dès qu’une interface réseau reçoit une adresse IP nouvelle ou modifiée, le client contrôle cet hôte. S’il n’est pas accessible, la connexion est activée. Le tunnel est établi automatiquement si les identifiants sont enregistrés ou si la dernière connexion a utilisé le SSO.

"auto_connect_host": "intranet.corp.example"

L’hôte de contrôle n’est pas un test général de l’état d’Internet. Il doit être stable, résolu en interne et ne pas être accessible depuis l’extérieur. Avant le déploiement, le test est réalisé depuis le réseau de l’entreprise et depuis un réseau externe. Une chaîne vide "" désactive la connexion automatique.

Pour un fonctionnement permanent, les identifiants enregistrés, le SSO, la MFA et le comportement après un changement de réseau doivent être coordonnés. Démarrer automatiquement SSL VPN avec la connexion automatique explique les différences.

Utiliser plusieurs passerelles

Plusieurs passerelles de portail sont saisies sous forme de tableau. gateway_order détermine uniquement la manière dont Sophos Connect sélectionne le portail pour la récupération. Le tunnel ultérieur utilise les passerelles de la configuration .scx ou .ovpn importée.

[
  {
    "display_name": "Avanet Remote Access",
    "gateway_order": "in_order",
    "gateway": [
      "vpn-zrh.example.com",
      "vpn-ber.example.com"
    ],
    "vpn_portal_port": 443,
    "otp": false,
    "can_save_credentials": false,
    "check_remote_availability": true,
    "run_logon_script": false
  }
]

Les modes de sélection ont des effets opérationnels différents :

• in_order essaie les entrées dans l’ordre défini.
• latency sélectionne la passerelle selon le temps de réponse d’une tentative de connexion TCP.
• distributed sélectionne une passerelle au hasard lors d’une tentative de connexion.

L’ordre ne remplace pas une conception WAN, DNS ou HA testée. Chaque nom de portail indiqué doit disposer d’un certificat valide, être joignable comme prévu et fournir le même contenu de provisioning attendu.

Il faut distinguer ce cas de celui de plusieurs connexions. Deux objets distincts dans le tableau JSON externe créent deux entrées dans Sophos Connect, par exemple une pour les collaborateurs et une pour les administrateurs. En revanche, un seul objet contenant plusieurs valeurs dans le champ gateway reste une connexion unique avec plusieurs passerelles de provisioning. Avant de combiner les deux variantes, définir les noms, les groupes cibles et les solutions de repli.

Définir les champs MFA de manière consciente

Avec otp: true, Sophos Connect affiche un troisième champ de saisie. 2fa détermine la manière dont son contenu est envoyé au serveur d’authentification :

• 2fa: 1 utilise la configuration de Sophos Firewall. Le mot de passe et l’OTP sont concaténés sous la forme passwordotp.
• 2fa: 2 utilise un service externe tel que Duo. Le mot de passe et le code sont séparés par une virgule ; selon la configuration Duo, push, phone, sms ou un code de token sont également possibles.

[
  {
    "display_name": "Avanet Remote Access MFA",
    "gateway": "vpn.example.com",
    "vpn_portal_port": 443,
    "otp": true,
    "2fa": 1,
    "can_save_credentials": false,
    "check_remote_availability": true,
    "run_logon_script": false
  }
]

Lors de la première récupération, l’écran de connexion peut s’afficher deux fois : une première fois pour télécharger la configuration, puis une seconde pour établir le tunnel. Ce comportement n’indique pas automatiquement une erreur. Le support doit le connaître avant un déploiement à grande échelle. La configuration MFA côté pare-feu est décrite dans Configurer la MFA sur Sophos Firewall.

Les étapes GPO et dossier d’import ci-dessous concernent Windows. Sur macOS à partir de 2.1, importez directement la .pro approuvée dans le client et testez séparément paquet, accès au portail, récupération du profil et connexion VPN ; ne transposez pas les chemins Windows ou les étapes GPO sur Mac.

Importer sous Windows et transmettre au déploiement administré

Le fichier peut être fourni par téléchargement protégé puis importé manuellement. Les utilisateurs sélectionnent Import connection ou ouvrent le fichier .pro par double-clic. L’e-mail ne convient que si le transport et les destinataires sont maîtrisés ; aucun mot de passe, OTP ou jeton utilisateur ne doit figurer dans le fichier.

Sophos Connect surveille ce dossier d’importation :

C:\Program Files (x86)\Sophos\Connect\import\

Un fichier .pro placé dans ce dossier est importé automatiquement, puis supprimé du dossier. Cette suppression est normale et ne prouve pas que l’authentification au portail ou le tunnel fonctionne déjà. Ce transfert par dossier constitue l’interface avec le déploiement administré.

Les scripts de démarrage GPO, le package client, SCCLI, les codes de sortie et le retour arrière complet relèvent du guide Déployer Sophos Connect sur des postes Windows administrés. Ce processus transmet le fichier .pro approuvé au client déjà installé comme artefact distinct et versionné, afin de vérifier séparément le déploiement du package et le provisioning des profils.

Pour l’import pilote, consignez la version ou l’empreinte approuvée du fichier source, déposez-le dans le dossier d’importation, puis vérifiez la connexion qui apparaît réellement dans le client. La source ne doit être lisible que par les appareils prévus, doit utiliser un certificat approuvé et ne doit contenir aucun identifiant dans une URL ou un script. Installer Sophos Connect sous Windows décrit en complément l’installation et les plateformes Windows prises en charge.

Un fichier .pro ne contient normalement aucun mot de passe utilisateur. Il reste néanmoins un artefact de configuration contrôlé : les adresses du portail, le comportement, la MFA et les paramètres de connexion automatique doivent provenir uniquement d’une source autorisée.

Métadonnées .pro réutilisables et identité SSL

Le fichier .pro brut contient des métadonnées de provisioning réutilisables, pas le certificat SSL VPN ni la clé privée d’un utilisateur. La documentation client SFOS 22 le distingue du profil SSL généré à l’importation : ce profil et ses certificats sont associés à l’identité, à la méthode d’authentification et au domaine utilisés lors de l’importation. Pour une autre méthode ou un autre domaine, importez un .pro distinct ou le propre .ovpn de l’utilisateur ; réutiliser le profil SSL importé peut provoquer Login failed. Wrong fingerprint of certificate. Cette restriction documentée ne s’applique pas aux profils IPsec .scx.

Un .ovpn contient des certificats et des clés privées propres à l’utilisateur : ne le partagez jamais entre utilisateurs. Réutiliser les métadonnées .pro brutes approuvées ne signifie pas partager un profil SSL généré ni exporter les clés d’un autre utilisateur. Importation et connexion sous Windows et sous macOS décrivent les étapes client ; appliquez cette précision de version aux conseils sur la liaison SSL et l’empreinte.

La documentation client SFOS 23 sauvegardée omet la section SFOS 22 sur la liaison d’identité sans expliquer de changement de comportement à l’exécution. Cette omission ne prouve ni un assouplissement de la réutilisation ni une liaison inchangée sur toutes les versions. En attendant une clarification faisant autorité pour la version concernée, séparez par précaution les importations SSL par identité, méthode et domaine ; cette précaution n’est pas une règle d’exécution SFOS 23 vérifiée.

Modifications et mises à jour des profils

Après une importation réussie, Sophos Connect récupère automatiquement les profils .scx et .ovpn disponibles ainsi que les modifications ultérieures de ces configurations. Il faut néanmoins distinguer le chemin de récupération défini dans le fichier .pro du profil VPN récupéré :

• Si gateway ou vpn_portal_port change, mettre à jour et redistribuer le fichier .pro.
• Si le port ou le protocole change sous SSL VPN global settings, les utilisateurs doivent cliquer sur l’icône d’engrenage de la connexion dans le client, puis sur Update policy.
• Le client récupère automatiquement les autres modifications du profil VPN fourni. Les modifications de la passerelle, du certificat serveur, du port ou du protocole SSL VPN peuvent nécessiter une nouvelle connexion.
• Si gateway et le port du portail VPN restent inchangés après une restauration ou une importation de configuration, le fichier récupère automatiquement les configurations IPsec et SSL VPN concernées.
• Si ce chemin a changé, redistribuer et réimporter le fichier .pro.
• Sans fichier .pro fonctionnel, réimporter les configurations IPsec concernées ; après une modification du port, du protocole, de l’interface ou du certificat serveur SSL VPN, télécharger à nouveau le fichier .ovpn depuis le portail VPN et le réimporter.
• Une mise à jour client n’est pas un substitut à la redistribution contrôlée d’un fichier .pro modifié.

Les anciens et nouveaux fichiers de provisioning ne doivent pas être distribués en parallèle par différentes GPO, téléchargements et e-mails. Pour chaque déploiement, le nom du fichier, la version ou la date de modification, le groupe cible et la solution de repli doivent être documentés.

Valider le provisioning et le tunnel

Le test est réalisé avec un utilisateur autorisé et un utilisateur non autorisé depuis un véritable réseau externe. Une authentification réussie au portail ne constitue pas à elle seule un test VPN réussi.

1. Vérifiez la version de Sophos Connect et la plateforme Windows.
2. Importez le fichier .pro manuellement ou via la GPO pilote.
3. Vérifiez quelles connexions .scx et .ovpn apparaissent réellement.
4. Effectuez tout le processus MFA, y compris l’éventuelle deuxième connexion.
5. Connectez IPsec et SSL VPN séparément si les deux sont proposés.
6. Vérifiez l’adresse attribuée, la résolution DNS interne, le serveur de destination, la règle du pare-feu et le chemin de retour.
7. Pour l’utilisateur non autorisé, distinguez l’importation du profil de l’accès : un profil IPsec peut apparaître, mais le tunnel ou l’accès interne doit échouer à l’étape prévue d’authentification ou d’application de la stratégie. Aucun fichier SSL VPN .ovpn ne doit être importé sans stratégie correspondante.
8. Testez les deux chemins de mise à jour : une modification normale du profil doit arriver automatiquement via le fichier .pro importé ; après une modification du port ou du protocole SSL VPN, sélectionnez Update policy dans le client.
9. Testez un redémarrage du client, un changement de réseau et un nouveau transfert par la méthode de déploiement choisie.
10. Testez le repli manuel sur un profil .scx ou .ovpn approuvé.

Avec Microsoft Entra ID SSO, il faut également contrôler la Redirect URI, Conditional Access et la reconnexion forcée sur les terminaux partagés. Microsoft Entra ID SSO pour Sophos Connect et le portail VPN décrit le mappage complet.

Pour le pilote SSO, consignez la version du firmware, la version du client et l’IdP. Utilisez la branche de version choisie ci-dessus, vérifiez l’affectation du même IdP aux services de provisioning et testez séparément la récupération au portail et le tunnel avec des utilisateurs autorisés et non autorisés. Les conseils d’identité SSL restent limités à la version documentée ; un pilote réussi ne résout pas de manière générale le conflit restant dans la documentation source SFOS 23.

Délimiter systématiquement les erreurs

Aucune connexion n’est importée

Vérifier d’abord que le fichier contient un JSON valide, se termine par .pro et a été importé par le client. Contrôler ensuite gateway, vpn_portal_port, le DNS, la chaîne de certificats et l’accessibilité du portail VPN. La disparition d’un fichier du dossier d’importation indique qu’il a été traité, mais ne prouve pas une authentification réussie.

Si le client atteint le portail sans recevoir de profil, vérifier la connexion IPsec configurée, la stratégie SSL VPN, l’appartenance aux groupes et les méthodes d’authentification. Le fichier IPsec .scx est fourni à tous les utilisateurs ; un fichier SSL VPN .ovpn uniquement aux membres d’une stratégie correspondante.

Erreurs de certificat ou de SSO

Le nom public dans gateway doit correspondre au certificat et à l’hôte du pare-feu dans la section Redirect URI de l’IdP configuré. Vérifiez vpn_portal_port séparément. En provisioning SSO, le portail VPN, IPsec et SSL VPN doivent utiliser le même IdP. Validez séparément la récupération au portail et l’authentification du tunnel pour la branche SFOS/client/fournisseur choisie ; un profil visible ou un Test connection réussi ne prouve ni l’une ni l’autre.

Pour Entra, corrélez la tentative avec Entra sign-in log, y compris MFA et Conditional Access. Suivez le diagnostic propre à la version dans Entra ID VPN SSO : ses anciens noms de journaux SSO concernent SFOS 22, pas tous les déploiements OIDC. Pour Google sous SFOS 23, suivez le dépannage Google Workspace OIDC. Ne transposez pas les instructions de journaux ou de redémarrage d’un fournisseur entre versions.

La MFA s’affiche deux fois ou échoue

Deux connexions peuvent être attendues lors de la première récupération. En cas d’échec, comparer otp, 2fa, la méthode MFA Sophos ou externe configurée et le format de saisie attendu. passwordotp et la méthode externe séparée par une virgule ne sont pas interchangeables.

Le profil existe, mais le trafic ne fonctionne pas

Le provisioning a alors dépassé le point où se situe réellement l’erreur. Vérifier séparément la plage d’attribution, les routes du client, le DNS, la règle de pare-feu, la NAT, le chemin de retour et la capture de paquets. Pour IPsec, poursuivre avec Dépannage VPN IPsec sur Sophos Firewall.

Le transfert administré n’importe pas le fichier

Tester d’abord l’importation manuelle du même fichier approuvé. Si elle fonctionne, l’erreur se trouve dans le transfert et non dans le schéma .pro. Vérifier ensuite l’état du service, le contexte système, l’accès à la source, les droits et le chemin d’importation exact. Poursuivre le diagnostic du package, de la GPO et de SCCLI dans le guide du déploiement Windows administré. Une redistribution aveugle sans recherche de cause ne remplace pas un diagnostic.

Revenir en arrière en toute sécurité

Pour revenir en arrière, arrêter d’abord le déploiement vers le groupe cible concerné afin d’éviter toute nouvelle importation. L’arrêt du transfert n’efface pas les connexions déjà importées. Sur les appareils pilotes, les supprimer ou les remplacer de manière contrôlée avant d’importer et de tester le fichier manuel .scx ou .ovpn préalablement approuvé. Ne rétablir les anciens paramètres du portail VPN, de Device Access ou de l’authentification que lorsqu’aucun provisioning en production n’en dépend plus.

Supprimer et réimporter de manière contrôlée la connexion Sophos Connect existante sur les clients de test. Répéter ensuite les tests de connexion au portail, du tunnel, du DNS, des destinations internes et le test négatif. Ne supprimer le fichier .pro défectueux des dépôts centraux et de la distribution logicielle qu’une fois la solution de repli opérationnelle.

FAQ