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. L’utilisateur peut alors scanner le code QR sur VPN Portal. 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. 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.

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 à insérer dans le bookmark sous Public host key. 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.
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 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.
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 soit un mot de passe, soit une Private Key. Sous Public host key, enregistrer la Host Key publique vérifiée 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.

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.

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 et ajouter les bookmarks existants avec Add new item. 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.

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 pour les connexions au VPN Portal avec SSO.

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.

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.