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 peut servir de cible, mais Sophos Firewall doit le résoudre de manière fiable et il doit pointer vers le système prévu. Une cible changeant fréquemment ne doit pas être considérée comme un scénario Dynamic DNS mis à jour de manière fiable.

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 sous Protocol security.
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.

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 Accept avec Source zone: WAN, le Source Network / Host concret, l’adresse de Sophos Firewall requise comme Destination host et Services: VPN portal. 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. 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 partagent le même port et le même protocole, leurs zones accessibles peuvent s’influencer mutuellement ; cet effet du partage de port doit être contrôlé séparément.

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. 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.

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é.

Autres types de bookmarks

SFOS 22 documente également :

VNC pour l’accès graphique aux systèmes Linux ou UNIX configurés en conséquence.
FTP, FTPS, SFTP et SMB pour l’accès à des serveurs de fichiers dans le navigateur. Cela ne crée pas de lecteur réseau monté de manière classique. Pour les données confidentielles, préférer SFTP ou FTPS à FTP non chiffré.
Telnet comme type de terminal. Comme Telnet 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.

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

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

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.