Configurer Clientless SSL VPN pour RDP et SSH sur Sophos Firewall

Avec Clientless SSL VPN, Sophos Firewall fournit directement dans le navigateur des connexions individuelles à des serveurs internes RDP, SSH, VNC ou de fichiers. L’utilisateur n’installe aucun client VPN et ne reçoit pas d’accès général à un réseau interne. Il se connecte au VPN Portal et ne voit que les bookmarks publiés par la clientless policy qui lui est attribuée.

Le nom similaire conduit facilement à la mauvaise configuration : Clientless Users associe en interne une IP fixe à une identité. Il ne publie aucun bookmark et ne fait pas partie de cette procédure de Remote Access.

La connexion au VPN Portal et celle à la cible sont deux étapes distinctes. Clientless SSL VPN ne prend pas en charge la transmission des identifiants : le mot de passe du VPN Portal n’est pas automatiquement transmis comme identifiant Windows ou SSH. Deux connexions sont donc normales tant qu’aucun identifiant de la cible n’est enregistré dans le bookmark.

Le déroulement principal est court :

Définir un système cible fixe, un port et le groupe d’utilisateurs autorisé.
Créer un bookmark RDP ou SSH sous Remote access VPN > Clientless SSL VPN policy > Bookmarks.
Associer le groupe d’utilisateurs et le bookmark sous Policies.
Sécuriser le VPN Portal, le certificat, l’authentification, la MFA et Device Access.
Tester l’accès depuis l’extérieur sous VPN > Clientless access connections avec un utilisateur autorisé et un utilisateur non autorisé.

Quand Clientless SSL VPN convient et quand ce n’est pas le cas

Clientless Access convient particulièrement à quelques cibles fixes, à des accès occasionnels ou à des techniciens externes lorsqu’aucun client VPN ne doit être installé sur l’appareil utilisé. Il n’est alors pas nécessaire de publier RDP et SSH directement sur Internet par DNAT. C’est le VPN Portal sécurisé qui est accessible publiquement.

Il ne remplace toutefois pas tous les Remote Access VPN :

Clientless SSL VPN convient à des cibles statiques RDP, SSH, VNC ou à des serveurs de fichiers individuels utilisables dans le navigateur.
Sophos Connect avec IPsec ou SSL VPN convient mieux lorsqu’un appareil administré a besoin de plusieurs réseaux, d’applications natives, de DNS ou de différents protocoles. L’aide au choix d’un accès à distance présente les différentes options.
ZTNA est conçu pour un accès durable limité aux applications, avec identité, état de l’appareil et policies centrales. Les principes sont expliqués dans Qu’est-ce que Zero Trust Network Access ?.
RD Gateway, un jump host ou PAM doivent être envisagés si l’administration privilégiée, les comptes cibles personnels, l’enregistrement des sessions ou les workflows d’approbation sont essentiels.

Pour RDP, il faut également savoir que le presse-papiers n’est plus pris en charge dans les sessions clientless depuis SFOS 19. Si le copier-coller ou d’autres fonctions RDP natives sont indispensables au workflow, un accès avec client ou une solution spécialisée constitue un meilleur choix.

Clientless SSL VPN ne prend pas en charge les adresses IP cibles dynamiques. Un nom d’hôte est autorisé comme cible, mais Sophos Firewall doit le résoudre de manière stable vers le système prévu. Une cible qui change fréquemment ne doit pas être planifiée comme un scénario Dynamic DNS mis à jour de manière fiable.

Le navigateur n’est que l’interface utilisateur : il établit la connexion HTTPS au VPN Portal, tandis que Sophos Firewall établit la seconde connexion vers la cible. Le bloqueur de fenêtres contextuelles doit autoriser la nouvelle fenêtre pour le FQDN du portail. SFOS 22 ne permet pas de publier des applications HTTP ou HTTPS internes quelconques sous forme de bookmarks Clientless ; selon le besoin, utilisez WAF ou ZTNA.

Prérequis et valeurs d’exemple

Avant la configuration, il faut clarifier la cible, l’identité et l’accès au portail :

Le système cible est accessible depuis Sophos Firewall par le routage et le DNS, et le service requis fonctionne.
Un utilisateur ou, de préférence, un groupe restreint existe sur Sophos Firewall ou sur le serveur d’authentification connecté.
Le VPN Portal possède un FQDN public ou accessible en interne et un certificat de confiance correspondant.
Une méthode adaptée est sélectionnée sous VPN portal authentication methods dans Authentication > Services.
La MFA et un accès de récupération indépendant sont préparés.
Il a été décidé si les identifiants de la cible peuvent être enregistrés dans le bookmark.

L’exemple RDP suivant utilise :

VPN Portal : https://vpn.example.com
Serveur cible : rdp-app01.intern.example
IP cible : 10.20.30.25
Port RDP : 3389
Bookmark : RDP-Fibu-Test
Groupe : Clientless-RDP-Fibu
Policy : Clientless-RDP-Fibu
Sécurité RDP pour le premier test : TLS
Automatic login : désactivé
Share session : désactivé

example.com est un domaine réservé aux exemples et 10.20.30.25 est une adresse privée d’exemple. Le FQDN, l’IP, le groupe et les noms doivent être remplacés par les valeurs de l’environnement concerné. Le port 3389 ne convient que si le serveur Windows utilise réellement le port RDP standard.

Configurer un bookmark RDP

Bookmark avec TLS et connexion personnelle à la cible

Sous Remote access VPN > Clientless SSL VPN policy > Bookmarks, créer un nouveau bookmark avec Add :

Saisir RDP-Fibu-Test sous Name.
Sélectionner RDP comme Type.
Saisir rdp-app01.intern.example ou l’IP fixe 10.20.30.25 sous URL.
Utiliser le port de service 3389. Un autre port ne doit être indiqué que s’il a été délibérément configuré autrement sur le système cible.
Laisser Automatic login désactivé pour le premier test.
Saisir si nécessaire le domaine réseau Windows, par exemple CORP ou corp.example.com.
Sélectionner TLS dans Protocol security. La troisième option, RDP, utilise la sécurité propre au protocole RDP ; Sophos recommande plutôt TLS ou NLA.
Laisser Share session désactivé.
Enregistrer avec Save.

Sans Automatic login, l’utilisateur saisit ses identifiants dans la fenêtre RDP qui s’ouvre. La connexion peut ainsi se faire avec un compte Windows personnel, si le modèle de sécurité du serveur cible autorise ce mode TLS.

Le certificat du VPN Portal et Protocol security: TLS remplissent des fonctions différentes. Le certificat du portail protège la connexion du navigateur à Sophos Firewall. Le paramètre RDP protège la connexion suivante, de Sophos Firewall au système Windows. Un certificat de portail valide ne remplace donc pas une sécurité RDP adaptée.

Si le serveur Windows exige NLA

De nombreux systèmes Windows exigent Network Level Authentication (NLA). Dans ce cas, sélectionner NLA dans le bookmark. SFOS active alors Automatic login, et le nom d’utilisateur ainsi que le mot de passe du système cible doivent être enregistrés dans le bookmark.

Il ne s’agit pas d’une simple option de confort. Tous les utilisateurs autorisés pour ce bookmark utilisent alors la même identité Windows enregistrée sur le système cible. Il faut exclusivement employer un compte dédié, doté des privilèges minimaux et dont les identifiants peuvent être renouvelés. Les comptes Domain Admin, les comptes d’administrateur personnels et les comptes de service disposant de privilèges étendus n’ont pas leur place dans un bookmark clientless.

NLA ne doit pas être désactivé sur le serveur Windows uniquement pour permettre le fonctionnement de l’exemple TLS. Si des identifiants enregistrés ou une identité cible partagée ne sont pas acceptables, Clientless RDP ne convient pas à ce serveur. Un VPN classique, RD Gateway, PAM ou un jump host contrôlé préserve mieux la traçabilité personnelle.

Laisser également Share session désactivé. Cette option est destinée à un cas de collaboration planifié. Dans une session partagée, Stop session met fin à la connexion pour tous les participants, tandis que Suspend session ne suspend que l’utilisateur actuel. Une session ne doit pas être partagée pour une administration privilégiée.

Bookmark VNC pour les systèmes Linux et UNIX

Un bookmark VNC suit le même principe de base, mais utilise Type: VNC. Sous URL, saisir l’adresse IP fixe du système cible ou un hostname dont la résolution est stable. Un autre port VNC ne doit être indiqué que si le service écoute réellement sur un port différent du port standard.

Avec Automatic login, SFOS enregistre le mot de passe de la cible dans le bookmark VNC. Si l’option reste désactivée, l’utilisateur saisit le mot de passe à l’ouverture de la connexion. Aucun nom d’utilisateur n’est configuré dans un bookmark VNC. Share session reste désactivé pour les accès individuels normaux et n’est utilisé que lorsqu’une session partagée est expressément requise.

ℹ️ La connexion au VPN Portal n’est pas non plus transmise au système cible pour VNC. Une connexion réussie au portail ne prouve donc ni que le mot de passe VNC est correct, ni que Sophos Firewall peut joindre le service VNC.

Configurer la clientless policy et le VPN Portal

Associer les utilisateurs et le bookmark dans une policy

La présence d’un bookmark ne suffit pas à rendre la cible visible pour un utilisateur. La policy associe l’identité et la ressource :

Ouvrir Remote access VPN > Clientless SSL VPN policy.
Sous Policies, cliquer sur Add.
Saisir Clientless-RDP-Fibu comme Name.
Sous Policy members, sélectionner uniquement le groupe Clientless-RDP-Fibu.
Sous Published bookmarks, sélectionner RDP-Fibu-Test.
Enregistrer avec Apply.

Un bookmark group n’est utile que si les mêmes utilisateurs ont besoin de plusieurs cibles. Pour une seule cible RDP, il ajoute uniquement un niveau d’administration.

Sécuriser le VPN Portal

Les utilisateurs ouvrent les connexions clientless via le VPN Portal. Le port par défaut est 443 ; le port et le certificat se configurent sous Administration > Admin and user settings > Admin console and end-user interaction. Dans cet exemple, le certificat doit contenir vpn.example.com comme SAN et être accepté par le navigateur sans avertissement. Importer et attribuer des certificats sur Sophos Firewall explique l’attribution générale des certificats.

Sous Administration > Device access, VPN portal doit être autorisé pour l’accès réellement nécessaire. Si le portail doit être accessible depuis toutes les sources WAN, activer WAN dans la matrice. Pour des réseaux sources connus, choisir l’option plus restrictive : laisser WAN désactivé dans la matrice et créer sous Local service ACL exception rule une règle avec Source zone: WAN, le Source Network / Host concret, l’adresse de Sophos Firewall requise comme Destination host, Services: VPN portal et Action: Accept. Une exception Accept supplémentaire ne restreint pas une autorisation WAN générale déjà activée dans la matrice. WebAdmin, User Portal, SSH ou SSL VPN ne sont pas automatiquement autorisés. Les Firewall Rules ne contrôlent pas ces services locaux. La planification sécurisée est expliquée dans Device Access et Local Service ACL.

⚠️ Un VPN Portal accessible depuis le WAN constitue une surface de connexion publique. Il ne doit pas être exploité sans MFA, certificat de confiance, appartenance restrictive à une policy et surveillance des connexions. Si VPN Portal et SSL VPN utilisent le même port, les Login security settings ne fonctionnent pas. S’ils utilisent également le même protocole, l’autorisation de SSL VPN depuis une zone rend aussi VPN Portal accessible, même s’il est désactivé pour cette zone sous Device access. Attribuer à chaque service local une combinaison port-protocole unique et contrôler à nouveau l’accès après chaque changement de port.

Pour Sophos OTP local, sélectionner d’abord Specific users and groups sous Authentication > Multi-factor authentication. Pour l’auto-enregistrement avec une application d’authentification, activer Generate OTP token with next sign-in, sélectionner VPN portal sous Require MFA for, puis enregistrer avec Apply. Ce flux direct de code QR sur VPN Portal concerne SFOS 22. Dans SFOS 23, lorsque Generate OTP token with next sign-in est activé, choisir également Share QR code avant Apply : Email envoie le code QR par e-mail à la prochaine connexion à VPN ou User Portal ; Portals l’affiche dans User Portal et VPN Portal après la prochaine connexion à VPN Portal, User Portal ou WebAdmin. Pour l’exemple de scan dans le portail, sélectionner explicitement Portals. SFOS 22 prend en charge SHA1, SHA256 et SHA512, et Sophos recommande SHA256 ou SHA512. L’application doit toutefois prendre en charge l’algorithme choisi : Intercept X for Mobile et Google Authenticator conviennent, tandis que Microsoft Authenticator peut scanner un code SHA256 ou SHA512, mais échoue ensuite à la connexion. Lors d’un changement d’algorithme, supprimer les tokens existants sous Issued tokens, puis faire scanner à nouveau le code QR. Avant la suppression, vérifier que Generate OTP token with next sign-in est activé pour ce flux. La remise du nouveau code QR suit la même distinction de versions : SFOS 22 l’affiche dans le portail ; SFOS 23 utilise Email ou Portals sous Share QR code, en conservant Portals pour cet exemple. Activer la MFA pour Sophos Firewall explique le pilote et la procédure de récupération. Le VPN Portal ne prend pas en charge la MFA RADIUS basée sur un challenge ; une méthode RADIUS existante doit donc être testée spécifiquement pour cette connexion au portail. Si le portail doit plutôt utiliser Microsoft Entra ID SSO et Conditional Access, Entra ID SSO pour Sophos Connect et VPN Portal décrit la chaîne d’identité complète.

Sous Authentication > Services, chaque méthode d’authentification accepte au maximum 20 serveurs. Les réglages globaux Maximum session timeout et Simultaneous logins ne sont pas propres à VPN Portal. SFOS contrôle l’autorisation toutes les trois minutes, et la limite de connexions simultanées s’applique uniquement aux utilisateurs ajoutés après sa définition. Ces limites ne doivent donc pas être considérées comme des contrôles d’accès immédiats propres au portail.

Tester l’accès depuis l’extérieur

Le test doit être effectué depuis un véritable réseau externe, par exemple via un hotspot mobile. Un test depuis le LAN ne prouve pas que le DNS, le certificat, Device Access et un routeur en amont fonctionnent correctement depuis Internet.

Ouvrir https://vpn.example.com dans une fenêtre de navigation privée.
Contrôler le nom du certificat, la chaîne de certificats et l’état affiché par le navigateur.
Se connecter avec un membre de Clientless-RDP-Fibu et terminer la MFA.
Sous VPN > Clientless access connections, vérifier que RDP-Fibu-Test apparaît.
Cliquer sur Connect. La session doit s’ouvrir dans une nouvelle fenêtre du navigateur.
Lorsque Automatic login est désactivé, saisir les identifiants Windows personnels et vérifier la connexion RDP.
Se déconnecter correctement du système Windows, puis quitter le VPN Portal.
Effectuer un test avec un utilisateur extérieur au groupe. Le bookmark ne doit pas apparaître pour cet utilisateur.
Retirer provisoirement l’utilisateur de test du groupe de la policy et vérifier que l’accès disparaît après une nouvelle connexion.

La réussite ne se limite pas à l’affichage d’un bureau. L’utilisateur du test positif voit exactement les bookmarks prévus, celui du test négatif n’en voit aucun, la MFA s’applique, le certificat est approuvé, la connexion à la cible fonctionne et la fin de session est traçable sur le portail comme sur le système cible.

Utiliser les commandes de session et de clavier dans le navigateur

Dans les sessions RDP, VNC, SSH et Telnet, placer le pointeur en haut de l’écran distant pour afficher les options de session. Connection propose Stop session et Suspend session. Après Suspend session, le même utilisateur reprend la session lorsqu’il clique à nouveau sur Connect dans le VPN Portal. Les autres participants à une session partagée continuent de travailler ; Stop session, en revanche, la termine pour tous.

Pour les connexions RDP et VNC, Keyboard permet de sélectionner des raccourcis clavier et de changer la langue du clavier. Pour appliquer une langue de la liste autre que l’anglais, la procédure documentée exige que la langue du serveur cible soit réglée sur US English. Ce prérequis concerne le choix de langue sous Keyboard, et non le presse-papiers.

Options pour SSH, VNC et les serveurs de fichiers

Bookmark SSH avec Host Key vérifié

Pour SSH, sélectionner SSH comme Type sous Bookmarks > Add. Cet exemple utilise srv-linux01.intern.example, le port 22 et l’utilisateur clientless-test.

Le Public host key doit appartenir au serveur attendu. Sur une cible Linux, afficher le Host Key public directement dans la console de confiance du serveur et documenter son fingerprint :

sudo cat /etc/ssh/ssh_host_ed25519_key.pub
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Ces commandes s’exécutent sur le serveur Linux cible, et non sur Sophos Firewall. Si le serveur utilise un autre type de Host Key, adapter le nom du fichier. Ne jamais accepter aveuglément un Key issu d’un avertissement de navigateur non vérifié ou d’un scan réseau quelconque.

La première commande affiche le Host Key ED25519 public comme exemple d’identification sur la console de confiance du système cible. Cela ne confirme pas que le build SSH clientless installé accepte ED25519 ou la représentation OpenSSH affichée sous Public host key. Avant l’insertion, confirmer à la fois l’algorithme accepté et la représentation sérialisée de la clé publique à l’aide de la documentation officielle SSH clientless applicable à ce build ou avec Sophos Support. La prise en charge de SSH par Linux, les paramètres SSH de WebAdmin, SFTP et des textes sources identiques ne prouvent pas cette compatibilité du champ. La seconde affiche uniquement le fingerprint destiné à la comparaison documentée ; le fingerprint ne doit pas être copié dans le champ à la place du Key.

Créer ensuite le bookmark SSH complet :

Sous Name, saisir par exemple SSH-Linux-Test.
Sélectionner SSH comme Type.
Saisir srv-linux01.intern.example sous URL et 22 comme port.
Sous Username, saisir clientless-test ou l’utilisateur cible prévu.
Laisser Automatic login désactivé si l’utilisateur doit saisir lui-même le mot de passe de la cible.
Insérer sous Public host key le Host Key public vérifié directement sur le système cible seulement après confirmation de l’algorithme et de la représentation pour le build SSH clientless installé.
Laisser Share session désactivé et enregistrer avec Save.
Ajouter le bookmark dans la clientless policy sous Published bookmarks et enregistrer avec Apply.
Dans le VPN Portal, cliquer sur Connect sous VPN > Clientless access connections, saisir le mot de passe de la cible et vérifier que le terminal attendu s’affiche. Fermer ensuite proprement la session SSH.

Sans Automatic login, l’utilisateur saisit le mot de passe de la cible lors de la connexion ; le nom d’utilisateur reste intégré au bookmark. Des noms d’utilisateur SSH personnels différents exigent donc des bookmarks distincts ou un autre mode d’accès. Avec Automatic login, SFOS peut utiliser un mot de passe ou une Private Key. Les Private Keys privilégiées ou largement utilisées ne doivent pas être enregistrées dans un bookmark partagé.

Serveurs de fichiers avec FTP, FTPS, SFTP ou SMB

Les bookmarks de serveurs de fichiers sont également créés sous Remote access VPN > Clientless SSL VPN policy > Bookmarks > Add. Les valeurs FTP, FTPS, SFTP et SMB sont disponibles sous Type. URL contient une adresse IP fixe ou un hostname stable ; Clientless SSL VPN ne prend pas en charge les adresses cibles dynamiques. Sous Init remote folder, il est possible de définir le dossier dans lequel l’utilisateur commence après la connexion.

Les méthodes se distinguent principalement par le transport et l’authentification sur la cible :

FTP, FTPS et SMB peuvent être utilisés avec ou sans Automatic login. Sans identifiants enregistrés, l’utilisateur se connecte au système cible après avoir ouvert le bookmark. FTP transmet les données sans chiffrement et ne doit pas être utilisé pour de nouveaux workflows externes.
Pour SMB, il est également possible de saisir le domaine réseau Windows auquel appartiennent le compte et le système cibles, par exemple CORP, corp.example ou corp.example.com. Ces exemples doivent être remplacés par le domaine réel de l’environnement.
FTPS protège la connexion FTP avec TLS. Sous Public host key, enregistrer également le certificat serveur attendu au format .pem. Le certificat et le nom sont vérifiés directement sur le système cible administré et non repris depuis une connexion non vérifiée.
SFTP utilise SSH. Le bookmark contient l’utilisateur cible et, sous Authentication method, Password ou Private key avec l’identifiant cible correspondant. Public host key sert à vérifier l’identité du serveur. La clé privée de l’utilisateur et la Host Key publique du serveur ont des fonctions différentes et ne doivent pas être confondues.

⚠️ Le format de saisie de Public host key pour SFTP reste à clarifier : les instructions sur les serveurs de fichiers pour SFOS 22 et 23 indiquent un certificat serveur au format .pem, tandis que les instructions distinctes pour SSH demandent une clé publique du serveur. Cela ne confirme ni une exigence X.509 ni l’acceptation de valeurs OpenSSH ou ED25519 dans le champ SFTP. Les commandes SSH ci-dessus ne constituent donc pas un guide de format pour SFTP. Avant la mise en production, clarifier avec Sophos Support la représentation acceptée pour SFTP dans le build installé et vérifier l’identité du serveur directement sur le système cible de confiance ; ne pas convertir les formats au hasard ni contourner la vérification d’identité.

Pour les bookmarks de serveurs de fichiers également, n’indiquer un autre port de service que si le service concerné sur le serveur cible utilise réellement un port différent du port par défaut.

Avec Automatic login, le nom d’utilisateur et le mot de passe du système cible sont enregistrés dans le bookmark pour FTP, FTPS et SMB. Tous les utilisateurs autorisés emploient alors cette identité cible enregistrée ; les mêmes exigences de privilèges minimaux et de rotation que dans l’exemple NLA s’appliquent. Il ne s’agit pas d’une transmission des identifiants du VPN Portal.

Dans cette procédure SFTP, SFOS s’authentifie automatiquement avec les identifiants de la cible enregistrés dans le bookmark. Le mot de passe de la cible n’est pas demandé à l’utilisateur ; la connexion interactive facultative de SSH, FTP, FTPS et SMB ne s’applique pas à SFTP.

Dans le navigateur, les sessions FTP, FTPS et SFTP permettent de transférer des fichiers, de créer des dossiers et de parcourir les répertoires. SFOS lance les téléchargements sans demande supplémentaire et les enregistre dans le dossier de téléchargement par défaut de l’appareil. Il faut donc valider les autorisations, le dossier initial et un test avec des fichiers non sensibles avant la mise en production. Un bookmark de serveur de fichiers ne crée pas un lecteur réseau Windows normal et ne remplace pas le contrôle des autorisations personnelles sur le serveur cible.

Les boutons en haut à droite des sessions FTP, FTPS et SFTP permettent d’arrêter la session, de téléverser un fichier, de créer un dossier et d’accéder au dossier parent.

Telnet reste disponible comme type de terminal, mais ne chiffre pas le transport. Il ne doit pas être utilisé pour de nouveaux accès. Les bookmarks HTTP et HTTPS ne font pas partie des types clientless actuellement documentés pour SFOS 22. Selon le niveau de protection requis, Web Application Firewall ou ZTNA constitue une architecture plus adaptée aux applications web internes.

Si un équipement ancien impose temporairement Telnet, sélectionner Type: Telnet sous Bookmarks > Add, saisir l’hôte fixe sous URL et ne définir le port que s’il diffère du port standard. Share session est facultatif. Limiter cet accès non chiffré à un groupe restreint et à une cible de gestion isolée, puis le remplacer par SSH.

Si les mêmes cibles doivent être affectées à plusieurs policies, créer un groupe sous Bookmark groups > Add : saisir le nom du groupe sous Name, sélectionner les bookmarks existants avec Add new item, puis enregistrer avec Save. La policy publie ensuite le groupe au lieu de chaque cible séparément. Un Bookmark Group n’étend pas les autorisations sur le système cible ; il simplifie uniquement l’affectation dans SFOS.

Lors de la création ou de la modification d’un groupe via la XML API, l’entité s’appelle SSLBookmarkGroup. La documentation de l’API pour SFOS 23.0 autorise les caractères UTF-8 dans son Name, interdit les virgules et maintient le maximum de 50 caractères. La documentation de SFOS 22.0 indique déjà ce maximum, mais pas les deux règles supplémentaires sur les caractères ; cela ne permet pas de conclure à leur application dans les builds antérieurs. Un exemple de nom conforme est Clientless-München, comme dans <Name>Clientless-München</Name> ; il doit être adapté à l’environnement. Après l’appel à l’API, contrôler le code d’état et le message de la réponse XML, puis relire le groupe enregistré : son nom et les bookmarks qu’il contient doivent correspondre à l’affectation prévue. Cette note concerne le nom du groupe dans l’API, sans imposer de règle générale aux noms des bookmarks individuels ; pour l’interface décrite ci-dessus, suivre les exigences des champs du build installé.

Bookmarks individuels via la XML API : L’exemple Add/Edit pour SSLBookmark dans SFOS 22.0 et 23.0 est une référence comportant des branches selon le type, et non un payload commun exécutable pour tous les protocoles. Les valeurs HTTP et HTTPS qu’il contient ne prouvent ni leur prise en charge actuelle dans l’interface ni leur prise en charge dans le build installé. Dans l’exemple, NLA exige que AutoLogin soit activé ; pour SSH/SFTP, le commentaire présente le mot de passe ou la Private Key comme deux possibilités lorsque AutoLogin est activé. Cela ne lève pas les restrictions décrites ci-dessus concernant les Host Keys SSH et les formats SFTP, et n’implique pas la possibilité d’une connexion SFTP interactive.

Le tableau des paramètres indique toutefois que Private Key, Public Host Key et UserName sont obligatoires, sans distinction de type. Il limite URL aux caractères utilisés dans les noms d’hôtes, tandis que la seconde ligne Domains, destinée à une liste de domaines/URL de redirection, exige un début par HTTP:// ou HTTPS://. Dans l’exemple, cette liste figure sous le token littéral RefferredDomains ; elle ne correspond pas au domaine Windows Domain pour RDP/SMB, même si le tableau contient également une ligne RDP nommée Domains. Ne pas renommer les tokens au hasard ni combiner les règles contradictoires du tableau en un payload universel. Avant toute modification automatisée, clarifier les champs, conditions et représentations acceptés pour le type et le build installé à l’aide de la documentation officielle applicable ou avec Sophos Support ; ne pas exécuter la modification non confirmée tant que ces points ne sont pas clarifiés. Au préalable, sauvegarder le bookmark réel et ses affectations comme état de référence ; après la modification, contrôler le statut et le message XML, puis relire le bookmark enregistré, son appartenance aux groupes et sa publication. En cas d’écart, annuler uniquement sa propre modification pour rétablir cet état de référence exact et répéter les tests d’accès ; ne pas inclure les mots de passe et les Private Keys dans les sorties d’audit ou dans des fichiers de payload non protégés.

Diagnostiquer les erreurs courantes

VPN Portal n’est pas accessible : contrôler l’entrée DNS publique, le port, le NAT en amont, Administration > Device access et un éventuel effet du partage de port.
La connexion au portail échoue : sous Authentication > Services, contrôler l’authentification du VPN Portal ainsi que l’état de l’utilisateur, la MFA et access_server.log.
Clientless access connections n’apparaît pas : l’utilisateur n’est attribué à aucune clientless policy ou la policy ne publie aucun bookmark.
Le bookmark est visible pour le mauvais utilisateur : contrôler Policy members, les appartenances aux groupes et Published bookmarks. Lorsque plusieurs groupes correspondent, Clientless SSL VPN peut combiner les autorisations des policies concernées. Les tests positif et négatif doivent vérifier quels bookmarks un utilisateur réel voit dans ce cas.
Le bookmark s’ouvre, mais la cible reste inaccessible : contrôler la résolution DNS du point de vue de Sophos Firewall, l’adresse cible statique, le routage, le port cible, l’état du service et le host firewall.
La connexion au VPN Portal fonctionne, mais pas celle à Windows : les connexions au portail et à la cible sont distinctes. Contrôler le domaine, le compte cible, le mot de passe ainsi que TLS ou NLA.
NLA active Automatic login : il s’agit du comportement documenté. Ne pas désactiver NLA sans planification ; réévaluer plutôt le modèle de compte et d’accès.
SSH signale un autre Host Key : arrêter la connexion et vérifier la modification directement sur le système cible ou auprès de l’exploitant responsable. Un Key inattendu peut indiquer une réinstallation, une mauvaise cible ou une attaque.

Sous Diagnostics > Tools > Troubleshooting logs, différents fichiers aident à analyser les différentes étapes :

vpnportal.log pour le VPN Portal ;
access_server.log pour l’authentification et l’autorisation ;
clientless_access.log pour les connexions clientless et l’établissement de la connexion à la cible ;
oauth_sso_vpn.log dans SFOS 22 pour les connexions à VPN Portal avec SSO ; dans SFOS 23, oauth_sso_svc.log pour OIDC/Entra SSO sur VPN Portal. Vérifier aussi le module Authentication dans Log viewer pour ces connexions à VPN Portal.

L’heure du test, l’utilisateur, le bookmark et la cible doivent être documentés ensemble. Il est alors possible de distinguer les problèmes de portail, d’identité et de cible dans les logs. Logs de service de Sophos Firewall explique l’affectation générale des logs et l’accès via Advanced Shell.

Exploitation et limites RDP connues

Avant une modification en production, consigner l’affectation de policy, la matrice Device Access, les exceptions ACL, le port du portail et le certificat. Si le test positif échoue ou si l’utilisateur négatif voit un bookmark, retirer la nouvelle affectation ou publication, restaurer ces valeurs à l’état antérieur, se reconnecter et répéter le test négatif. Ne restaurer les comptes cibles ou Host Keys que s’ils ont réellement été modifiés.

Les clientless policies doivent être contrôlées régulièrement comme les autres autorisations de Remote Access. Supprimer les utilisateurs, bookmarks et comptes cibles devenus inutiles. Les mots de passe ou Private Keys enregistrés doivent avoir un propriétaire, une date d’expiration et un processus de rotation. Automatic login et Share session doivent faire partie de chaque revue des autorisations.

Retirer une publication n’est pas supprimer : Avant tout retrait, clarifier s’il concerne un bookmark individuel ou un Bookmark Group, puis consigner le nom exact, l’appartenance actuelle aux groupes et la publication dans toutes les policies concernées. Commencer par retirer uniquement la publication ou l’affectation devenue indésirable ; cela ne supprime pas l’objet. Ne supprimer l’objet précis que lorsqu’il est réellement inutilisé et que ses dépendances ont été clarifiées. Si des relations subsistent, arrêter la procédure et ne pas supprimer en cascade des groupes ou des policies en production dans le seul but de forcer le retrait.

Les références Delete pour SFOS 22.0 et 23.0 exigent chacune un Name de 50 caractères au maximum et énumèrent les valeurs de statut XML 200, 500 et 504. Pour 504, elles renvoient à BookMarkDeleteRelationExists pour les bookmarks et à BookMarkGroupDeleteRelationExists pour les groupes : il s’agit d’identifiants de messages non résolus dans la documentation, et non de textes de messages confirmés à l’exécution ni d’un statut HTTP. Ces références ne fournissent ni payload d’exemple pour Delete ni garantie concernant les suppressions en cascade ; ne pas en déduire de syntaxe de suppression. Après la modification, relire effectivement les bookmarks et groupes restants ainsi que les publications prévues, puis répéter les tests positifs et négatifs. En cas d’accès inattendu, annuler ses propres modifications d’affectation pour rétablir l’état de référence consigné ; éviter pour cette raison les suppressions d’objets inutiles lorsqu’il s’agit simplement de retirer une publication.

Pour consulter en direct les utilisateurs distants connectés, ouvrir Current activities > Remote users dans la console d’administration. Les connexions peuvent être filtrées par date de connexion, nom d’utilisateur, adresse IP source et adresse IP attribuée (leased IP). L’administrateur peut cliquer sur Disconnect pour déconnecter l’utilisateur distant sélectionné. Vérifier d’abord l’utilisateur et la connexion, car cette action interrompt l’accès. Elle ne remplace ni le retrait de l’utilisateur de la clientless policy ni une déconnexion propre sur la cible, et ne garantit pas la fin de toutes les sessions en aval sur les systèmes cibles.

La documentation de la colonne Mode distingue les cas suivants :

SSL VPN (remote access) : l’utilisateur est connecté par SSL VPN d’accès distant.
User portal (clientless access) : selon cette correspondance, l’utilisateur est connecté au User Portal et appartient à une clientless SSL VPN policy.
User portal : selon cette correspondance, l’utilisateur est connecté au User Portal, mais n’appartient pas à une clientless SSL VPN policy.

Ces libellés proviennent des instructions Remote users pour SFOS 22 et 23. Les instructions Clientless désignent en revanche le VPN portal comme voie d’accès. La terminologie est donc incohérente ; cette liste ne confirme ni les libellés Mode actuels du build installé ni un changement de SFOS 22 à 23. Pour la configuration, conserver la procédure VPN Portal décrite ci-dessus. Vérifier séparément la connexion au portail, l’appartenance à la policy et les bookmarks réellement visibles, sans déduire une autorisation d’un seul libellé Mode.

Avant de changer de firmware, utilisez le runbook Avanet de décision sur le firmware pour identifier les changements qui concernent le build installé et la version cible. Incluez Clientless Access, VPN portal, RDP et la méthode d’authentification utilisée dans ce contrôle. Après la mise à niveau, répétez l’ensemble des tests positifs et négatifs.

RDP présente actuellement deux limites qui ne doivent pas être traitées comme des erreurs de configuration :

Le presse-papiers n’est plus pris en charge dans les bookmarks RDP clientless depuis SFOS 19. Le copier-coller entre l’appareil local et la session RDP ne constitue donc pas un workflow fiable.
Dans la session RDP HTML5, le pointeur de la souris peut prendre la forme d’une croix ou d’un X au lieu d’une flèche normale. Sophos n’indique actuellement aucune solution de contournement.

Si le presse-papiers, les fonctions RDP natives, un accès réseau plus étendu ou des comptes cibles personnels sur un serveur imposant NLA sans identifiants enregistrés sont indispensables, Clientless SSL VPN n’est pas le raccourci adapté. L’accès doit alors être migré de manière planifiée vers Sophos Connect, RD Gateway, PAM, un jump host ou ZTNA.