Configurer le provisioning Sophos Connect avec .pro et GPO

Un fichier de provisioning Sophos Connect portant l’extension .pro n’est pas un profil VPN complet. Il indique au client Windows le portail VPN à utiliser pour récupérer les configurations IPsec et SSL VPN autorisées pour l’utilisateur. Sophos Connect n’importe le véritable fichier .scx ou .ovpn qu’après une authentification réussie.

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.

⚠️ Le provisioning à distance nécessite que le portail VPN soit accessible depuis la zone WAN. Cela augmente la surface d’attaque exposée publiquement. Avant le déploiement, il faut un certificat approuvé, la MFA, des Local Service ACL restrictives, un blocage des connexions testé et une solution de repli avec un profil distribué manuellement.

Le provisioning en huit étapes

1. Configurer entièrement l’accès distant IPsec ou le SSL VPN sur le pare-feu et le tester avec un fichier importé manuellement.
2. Publier le portail VPN avec un FQDN et un certificat approuvés.
3. Sous Administration > Device access, n’autoriser le portail VPN que depuis les zones ou réseaux sources réellement nécessaires.
4. Créer un fichier .pro minimal avec display_name, gateway et vpn_portal_port.
5. N’ajouter la MFA, la connexion automatique et l’ordre des passerelles que lorsque le processus correspondant est défini.
6. Importer d’abord le fichier manuellement avec un utilisateur pilote et tester séparément IPsec et SSL VPN.
7. Déployer ensuite Sophos Connect et le fichier .pro sur un petit groupe pilote au moyen d’une GPO contrôlée.
8. Valider la connexion au portail, les profils importés, le tunnel, les destinations internes, les journaux, Update Policy et le retour arrière.

Quand utiliser un fichier .pro

Le provisioning convient 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 autorisés. Une configuration SSL VPN n’est importée que si l’utilisateur appartient à 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.

Un fichier .scx ou .ovpn distribué manuellement reste pertinent lorsque le portail VPN ne doit pas être publié sur Internet, que seuls quelques clients existent ou que le portail constitue une dépendance supplémentaire indésirable. Sophos Connect ne prend pas en charge le provisioning .pro sous macOS ; les fichiers .scx et .ovpn y sont importés directement. Le provisioning IPsec sous Windows nécessite Sophos Connect 2.1 ou une version ultérieure.

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.
• Avec Microsoft Entra ID SSO, le portail VPN, IPsec et SSL VPN utilisent le même serveur Entra ID sous Authentication > Services dans le processus de provisioning.
• Avec Entra ID SSO, la valeur gateway correspond à la Redirect URI du pare-feu.
• 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.

Créer le fichier de provisioning

Un fichier .pro utilise le format JSON. gateway est le seul champ obligatoire, mais il est préférable de définir explicitement un nom d’affichage et le port du portail pour faciliter le suivi. Le fichier est créé avec un éditeur de texte et enregistré, 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.

Au démarrage de la connexion, check_remote_availability contrôle l’accessibilité. run_logon_script exécute le script d’ouverture de session fourni par le contrôleur de domaine une fois le tunnel établi. Chaque option ne doit être activée que si le pilote confirme que ce comportement est réellement nécessaire.

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.

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.

Une conception always-on complète comporte d’autres limites. Les identifiants enregistrés, le SSO, la MFA et le comportement après un changement de réseau doivent être cohérents. Démarrer automatiquement le SSL VPN avec connexion automatique explique ces 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 renseigné nécessite un certificat valide, une accessibilité adaptée et le même contenu de provisioning attendu.

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.

Déployer Sophos Connect et .pro par GPO

Le fichier peut être importé manuellement après avoir été transmis par e-mail ou téléchargement sécurisé. Les utilisateurs sélectionnent Import connection ou ouvrent le fichier .pro par double-clic. Dans un domaine Windows géré, une GPO facilite la traçabilité si la source, le groupe cible et le retour arrière sont documentés.

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 un comportement normal et ne prouve pas que l’authentification au portail ou le tunnel fonctionne déjà.

Pour le déploiement, un script de démarrage est ajouté sous Group Policy Management > Computer Configuration > Policies > Windows Settings > Scripts > Startup. Le modèle documenté par Sophos attend le service scvpn, télécharge le fichier depuis un emplacement HTTPS central et le copie dans le dossier d’importation. La source de téléchargement ne devrait être lisible que par les ordinateurs nécessaires, utiliser un certificat approuvé et ne contenir aucun mot de passe utilisateur ni token dans l’URL ou le script.

Le script de démarrage est d’abord testé sur un ordinateur pilote. La stratégie peut ensuite être actualisée avec la commande suivante :

gpupdate /force

Sophos documente également un script de démarrage d’ordinateur utilisant msiexec.exe pour installer le client. Dans un déploiement logiciel en production, il convient toutefois d’appliquer les normes existantes de packaging, de signature, de version et de retour arrière. Installer Sophos Connect sous Windows décrit 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.

Modifications et mises à jour des profils

Après une importation réussie, Sophos Connect récupère automatiquement les profils .scx et .ovpn disponibles. Il récupère également de nombreuses modifications de configuration ultérieures. L’exploitation doit néanmoins distinguer le fichier de provisioning du profil VPN proprement dit :

• Si gateway ou vpn_portal_port change, le fichier .pro doit être modifié et redistribué.
• Si le port ou le protocole change sous SSL VPN global settings, il faut sélectionner l’icône en forme d’engrenage puis Update policy dans le client.
• Les modifications de passerelle, certificat, port ou protocole SSL VPN peuvent nécessiter une nouvelle connexion.
• Après la restauration ou l’importation d’une configuration du pare-feu, les profils IPsec et SSL VPN sont à nouveau testés avec un client pilote.
• Une nouvelle version du client ne met pas automatiquement à jour un fichier .pro obsolète.

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érifier la version de Sophos Connect et la plateforme Windows.
2. Importer le fichier .pro manuellement ou par la GPO pilote.
3. Contrôler quelles connexions .scx et .ovpn apparaissent réellement.
4. Effectuer l’intégralité du processus MFA, y compris une éventuelle seconde connexion.
5. Connecter séparément IPsec et SSL VPN si les deux sont proposés.
6. Vérifier l’adresse attribuée, la résolution DNS interne, le serveur cible, la règle de pare-feu et le chemin de retour.
7. Un utilisateur non autorisé ne doit recevoir aucun profil utilisable ni accéder aux destinations internes.
8. Tester une modification de stratégie sans risque avec Update policy ou la récupération automatique.
9. Tester un redémarrage du client, un changement de réseau et une nouvelle application de la GPO.
10. Tester la solution de repli manuelle avec 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.

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. IPsec est fourni à tous les utilisateurs dûment autorisés ; SSL VPN uniquement aux membres d’une stratégie correspondante.

Erreurs de certificat ou Entra SSO

Le nom public dans gateway doit correspondre au certificat. Avec Entra ID SSO, la même valeur doit également correspondre à la Redirect URI, et le portail VPN, IPsec et SSL VPN doivent utiliser le même serveur Entra ID dans le processus de provisioning. Une simple différence de nom d’hôte ou de port peut interrompre le processus.

La connexion Microsoft Entra est vérifiée dans Entra sign-in log. Sur le pare-feu, vpnportal.log, access_server.log et oauth_sso_vpn.log permettent d’analyser les étapes correspondantes. Test connection sur le serveur d’authentification ne remplace ni l’authentification au portail ni celle du tunnel.

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.

La GPO n’importe pas le fichier

Vérifier que la GPO s’applique réellement au compte d’ordinateur, que le script de démarrage est accessible, que le service scvpn est actif et que la source de téléchargement est accessible dans le contexte système. Contrôler ensuite les droits sur le fichier et le chemin d’importation exact. Des copies répétées sans recherche de la cause peuvent redistribuer des paramètres obsolètes et ne doivent pas devenir une solution permanente dans le script de démarrage.

Revenir en arrière en toute sécurité

Commencer par arrêter le déploiement vers le groupe cible de la GPO concernée. Supprimer ensuite le déploiement automatique du fichier .pro, fournir le fichier manuel .scx ou .ovpn précédemment approuvé et le tester avec un utilisateur pilote. Les modifications apportées au portail VPN, à Device Access ou à l’authentification ne sont annulées 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