Sophos Firewall Clientless SSL VPN für RDP und SSH einrichten

Mit Clientless SSL VPN stellt eine Sophos Firewall einzelne interne RDP-, SSH-, VNC- oder File-Server-Verbindungen direkt im Browser bereit. Der Benutzer installiert keinen VPN-Client und erhält keinen allgemeinen Zugriff auf ein internes Netz. Stattdessen meldet er sich am VPN Portal an und sieht nur die Bookmarks, die seine Clientless-Policy veröffentlicht.

Der ähnliche Name führt leicht in die falsche Konfiguration: Clientless Users ordnen intern eine feste IP einer Identität zu. Sie veröffentlichen keine Bookmarks und gehören nicht zu diesem Remote-Access-Ablauf.

VPN-Portal-Anmeldung und Zielanmeldung sind dabei zwei getrennte Schritte. Clientless SSL VPN unterstützt kein Credential Passthrough: Das Passwort für das VPN Portal wird nicht automatisch als Windows- oder SSH-Anmeldung weitergereicht. Zwei Anmeldungen sind deshalb normal, solange im Bookmark keine Zielzugangsdaten gespeichert werden.

Der Kernablauf ist kurz:

Festes Zielsystem, Port und berechtigte Benutzergruppe festlegen.
Unter Remote access VPN > Clientless SSL VPN policy > Bookmarks einen RDP- oder SSH-Bookmark erstellen.
Unter Policies die Benutzergruppe und den Bookmark miteinander verbinden.
VPN Portal, Zertifikat, Authentifizierung, MFA und Device Access absichern.
Zugriff von extern unter VPN > Clientless access connections mit einem berechtigten und einem unberechtigten Benutzer testen.

Wann Clientless SSL VPN passt – und wann nicht

Clientless Access eignet sich besonders für wenige feste Ziele, gelegentliche Zugriffe oder externe Techniker, wenn auf dem verwendeten Gerät kein VPN-Client installiert werden soll. RDP und SSH müssen dadurch nicht direkt per DNAT im Internet veröffentlicht werden. Öffentlich erreichbar ist stattdessen das abgesicherte VPN Portal.

Es ersetzt aber nicht jedes Remote-Access-VPN:

Clientless SSL VPN passt zu einzelnen statischen RDP-, SSH-, VNC- oder File-Server-Zielen, die im Browser bedient werden können.
Sophos Connect mit IPsec oder SSL VPN passt besser, wenn ein verwaltetes Gerät mehrere Netze, native Anwendungen, DNS oder unterschiedliche Protokolle benötigt. Die Remote-Access-Entscheidungshilfe ordnet die Varianten ein.
ZTNA ist für dauerhaft anwendungsbezogenen Zugriff mit Identität, Gerätezustand und zentralen Policies gedacht. Die Grundlagen stehen unter Was ist Zero Trust Network Access?.
RD Gateway, Jump Host oder PAM sollte man prüfen, wenn privilegierte Administration, persönliche Zielkonten, Sitzungsaufzeichnung oder Freigabeworkflows entscheidend sind.

Bei RDP ist ausserdem wichtig, dass die Zwischenablage in Clientless-Sitzungen seit SFOS 19 nicht unterstützt wird. Wenn Copy-and-paste oder andere native RDP-Funktionen für den Arbeitsablauf zwingend sind, ist ein clientbasierter oder spezialisierter Zugriffsweg die bessere Wahl.

Clientless SSL VPN unterstützt keine dynamischen Ziel-IP-Adressen. Ein Hostname ist zwar als Ziel erlaubt, muss aber von der Firewall stabil aufgelöst werden und auf das vorgesehene System zeigen. Ein häufig wechselndes Ziel sollte nicht als zuverlässig nachgeführtes Dynamic-DNS-Szenario geplant werden.

Der Browser ist dabei nur die Bedienoberfläche: Er baut die HTTPS-Verbindung zum VPN Portal auf, während die Firewall die zweite Verbindung zum Zielsystem herstellt. Pop-up-Blocker müssen das neue Sitzungsfenster für den Portal-FQDN erlauben. Beliebige interne HTTP- oder HTTPS-Anwendungen lassen sich in SFOS 22 nicht als Clientless-Bookmark veröffentlichen; dafür sind je nach Anforderung WAF oder ZTNA vorgesehen.

Voraussetzungen und Beispielwerte

Vor der Konfiguration sollten Ziel, Identität und Portalzugriff geklärt sein:

Das Zielsystem ist von der Firewall aus per Routing und DNS erreichbar, und der benötigte Dienst läuft.
Ein Benutzer oder eine möglichst enge Gruppe ist auf der Firewall beziehungsweise dem angebundenen Authentifizierungsserver vorhanden.
Das VPN Portal besitzt einen öffentlichen oder intern erreichbaren FQDN und ein dazu passendes, vertrauenswürdiges Zertifikat.
Unter Authentication > Services ist eine passende Methode unter VPN portal authentication methods ausgewählt.
MFA und ein unabhängiger Wiederherstellungszugang sind vorbereitet.
Es ist entschieden, ob Zielzugangsdaten im Bookmark gespeichert werden dürfen.

Das folgende RDP-Beispiel verwendet:

VPN Portal: https://vpn.example.com
Zielserver: rdp-app01.intern.example
Ziel-IP: 10.20.30.25
RDP-Port: 3389
Bookmark: RDP-Fibu-Test
Gruppe: Clientless-RDP-Fibu
Policy: Clientless-RDP-Fibu
RDP-Sicherheit für den ersten Test: TLS
Automatic login: deaktiviert
Share session: deaktiviert

example.com ist eine reservierte Beispieldomain und 10.20.30.25 eine private Beispieladresse. FQDN, IP, Gruppe und Namen müssen durch Werte aus der eigenen Umgebung ersetzt werden. Port 3389 bleibt nur dann richtig, wenn der Windows-Server tatsächlich den RDP-Standardport verwendet.

RDP-Bookmark einrichten

Bookmark mit TLS und persönlicher Zielanmeldung

Unter Remote access VPN > Clientless SSL VPN policy > Bookmarks wird mit Add ein neuer Bookmark erstellt:

Unter Name RDP-Fibu-Test eintragen.
Als Type RDP auswählen.
Unter URL rdp-app01.intern.example oder die feste IP 10.20.30.25 eintragen.
Den Service-Port 3389 verwenden. Ein abweichender Port wird nur eingetragen, wenn er auf dem Zielsystem bewusst anders konfiguriert ist.
Automatic login für den ersten Test deaktiviert lassen.
Bei Bedarf die Windows-Netzwerkdomäne eintragen, beispielsweise CORP oder corp.example.com.
Unter Protocol security TLS auswählen. Die dritte Option RDP verwendet die protokolleigene RDP-Sicherheit; Sophos empfiehlt stattdessen TLS oder NLA.
Share session deaktiviert lassen.
Mit Save speichern.

Ohne Automatic login gibt der Benutzer seine Zugangsdaten im geöffneten RDP-Fenster ein. Damit kann die Anmeldung mit einem persönlichen Windows-Konto erfolgen, sofern das Sicherheitsmodell des Zielservers diesen TLS-Modus zulässt.

Das Zertifikat des VPN Portals und Protocol security: TLS erfüllen unterschiedliche Aufgaben. Das Portalzertifikat schützt die Browserstrecke zur Firewall. Die RDP-Einstellung schützt die nachgelagerte Verbindung von der Firewall zum Windows-System. Ein gültiges Portalzertifikat ersetzt deshalb keine passende RDP-Sicherheit.

Wenn der Windows-Server NLA verlangt

Viele Windows-Systeme verlangen Network Level Authentication (NLA). In diesem Fall wird im Bookmark NLA ausgewählt. SFOS aktiviert dadurch Automatic login, und Benutzername sowie Passwort des Zielsystems müssen im Bookmark hinterlegt werden.

Das ist keine reine Komfortoption. Alle berechtigten Benutzer dieses Bookmarks arbeiten dann auf dem Zielsystem mit derselben gespeicherten Windows-Identität. Dafür sollte nur ein dediziertes, minimal berechtigtes und rotierbares Konto verwendet werden. Domain-Admin-Konten, persönliche Administratorkonten und breit berechtigte Servicekonten gehören nicht in einen Clientless-Bookmark.

NLA sollte nicht nur deshalb am Windows-Server deaktiviert werden, damit der TLS-Beispielweg funktioniert. Wenn gespeicherte Zugangsdaten oder eine gemeinsame Zielidentität nicht akzeptabel sind, passt Clientless RDP für diesen Server nicht. Ein reguläres VPN, RD Gateway, PAM oder ein kontrollierter Jump Host erhält die persönliche Nachvollziehbarkeit besser.

Share session bleibt ebenfalls aus. Die Option ist für einen bewusst geplanten Kollaborationsfall gedacht. Bei einer geteilten Sitzung beendet Stop session die Verbindung für alle Teilnehmer, während Suspend session nur den aktuellen Benutzer pausiert. Für privilegierte Administration sollte eine Sitzung nicht geteilt werden.

VNC-Bookmark für Linux- und UNIX-Systeme

Ein VNC-Bookmark folgt demselben Grundprinzip, verwendet aber Type: VNC. Unter URL wird die feste IP-Adresse oder der stabil auflösbare Hostname des Zielsystems eingetragen. Ein abweichender VNC-Port gehört nur dann in das Bookmark, wenn der Dienst tatsächlich nicht auf seinem Standardport lauscht.

Bei Automatic login speichert SFOS für VNC das Zielpasswort im Bookmark. Bleibt die Option aus, gibt der Benutzer das Passwort beim Öffnen der Verbindung ein. Ein Benutzername wird im VNC-Bookmark nicht konfiguriert. Share session bleibt für normale Einzelzugriffe deaktiviert und wird nur verwendet, wenn eine gemeinsame Sitzung fachlich gewollt ist.

ℹ️ Die Anmeldung am VPN Portal wird auch bei VNC nicht an das Zielsystem weitergereicht. Ein erfolgreicher Portal-Login beweist deshalb weder, dass das VNC-Passwort stimmt, noch dass der VNC-Dienst von der Firewall erreichbar ist.

Clientless-Policy und VPN Portal konfigurieren

Benutzer und Bookmark in einer Policy verbinden

Ein vorhandener Bookmark allein macht das Ziel noch keinem Benutzer sichtbar. Erst die Policy verbindet Identität und Ressource:

Remote access VPN > Clientless SSL VPN policy öffnen.
Unter Policies auf Add klicken.
Als Name Clientless-RDP-Fibu eintragen.
Unter Policy members nur die Gruppe Clientless-RDP-Fibu auswählen.
Unter Published bookmarks RDP-Fibu-Test auswählen.
Mit Apply speichern.

Eine Bookmark Group lohnt sich erst, wenn dieselben Benutzer mehrere Ziele benötigen. Für ein einzelnes RDP-Ziel erzeugt sie nur eine zusätzliche Verwaltungsebene.

VPN Portal absichern

Der Benutzer öffnet Clientless-Verbindungen über das VPN Portal. Der Standardport ist 443; Port und Zertifikat stehen unter Administration > Admin and user settings > Admin console and end-user interaction. Für das Beispiel muss das Zertifikat vpn.example.com als SAN enthalten und vom Browser ohne Warnung akzeptiert werden. Die allgemeine Zertifikatszuweisung erklärt Zertifikate auf Sophos Firewall importieren und zuweisen.

Unter Administration > Device access muss VPN portal für den tatsächlich benötigten Zugriff erlaubt werden. Soll das Portal aus allen WAN-Quellen erreichbar sein, wird WAN in der Matrix aktiviert. Bei bekannten Quellnetzen ist die engere Variante besser: WAN in der Matrix deaktiviert lassen und unter Local service ACL exception rule eine Accept-Regel mit Source zone: WAN, dem konkreten Source Network / Host, der benötigten Firewall-Adresse als Destination host, Services: VPN portal und Action: Accept erstellen. Eine zusätzliche Accept-Ausnahme verengt eine bereits pauschal aktivierte WAN-Matrixfreigabe nicht. WebAdmin, User Portal, SSH oder SSL VPN werden dadurch nicht automatisch ebenfalls freigegeben. Firewall Rules steuern diese lokalen Dienste nicht. Die sichere Planung steht unter Device Access und Local Service ACL.

⚠️ Ein aus WAN erreichbares VPN Portal ist eine öffentliche Loginfläche. Es sollte nicht ohne MFA, vertrauenswürdiges Zertifikat, enge Policy-Mitgliedschaft und Login-Monitoring betrieben werden. Verwenden VPN Portal und SSL VPN denselben Port, greifen die Login security settings nicht. Teilen sie zusätzlich dasselbe Protokoll, macht eine Zonenfreigabe für SSL VPN auch das VPN Portal erreichbar, selbst wenn es für diese Zone in Device access deaktiviert ist. Deshalb für lokale Dienste jeweils eine eindeutige Port-Protokoll-Kombination verwenden und die Erreichbarkeit nach jeder Portänderung erneut kontrollieren.

Für lokales Sophos OTP wird unter Authentication > Multi-factor authentication zunächst Specific users and groups verwendet. Für die Selbstregistrierung per Authenticator-App wird Generate OTP token with next sign-in aktiviert, unter Require MFA for das VPN portal ausgewählt und mit Apply gespeichert. Der Benutzer kann den QR-Code dann am VPN Portal scannen. SFOS 22 unterstützt SHA1, SHA256 und SHA512; Sophos empfiehlt SHA256 oder SHA512. Die App muss den gewählten Algorithmus jedoch unterstützen: Sophos nennt Intercept X for Mobile und Google Authenticator als passende Beispiele; Microsoft Authenticator kann den QR-Code mit SHA256 oder SHA512 zwar scannen, die Anmeldung schlägt danach aber fehl. Bei einem Algorithmuswechsel werden die vorhandenen Tokens unter Issued tokens gelöscht und anschliessend neu gescannt. Die Pilotierung und der Wiederherstellungsweg stehen in MFA für Sophos Firewall aktivieren. Das VPN Portal unterstützt kein challenge-basiertes RADIUS-MFA; ein bestehendes RADIUS-Verfahren muss deshalb genau für diesen Portal-Login getestet werden. Wenn das Portal stattdessen Microsoft Entra ID SSO und Conditional Access verwenden soll, beschreibt Entra ID SSO für Sophos Connect und VPN Portal die vollständige Identity-Kette.

Unter Authentication > Services lassen sich pro Authentifizierungsmethode höchstens 20 Server auswählen. Die globalen Werte Maximum session timeout und Simultaneous logins gelten nicht nur für das VPN Portal. SFOS prüft die Autorisierung alle drei Minuten; die Begrenzung gleichzeitiger Anmeldungen gilt ausserdem nur für Benutzer, die nach dem Setzen des Werts hinzugefügt werden. Diese Limits deshalb nicht als sofort wirkende, portalspezifische Zugriffskontrolle einplanen.

Zugriff von extern testen

Der Test sollte aus einem echten externen Netz erfolgen, beispielsweise über einen Mobilfunk-Hotspot. Ein Test aus dem LAN beweist nicht, dass DNS, Zertifikat, Device Access und ein vorgelagerter Router aus dem Internet korrekt zusammenspielen.

https://vpn.example.com in einem privaten Browserfenster öffnen.
Zertifikatsname, Zertifikatskette und Browserstatus kontrollieren.
Mit einem Mitglied von Clientless-RDP-Fibu anmelden und MFA abschliessen.
Unter VPN > Clientless access connections prüfen, ob RDP-Fibu-Test erscheint.
Connect anklicken. Die Sitzung muss sich in einem neuen Browserfenster öffnen.
Bei deaktiviertem Automatic login die persönlichen Windows-Zugangsdaten eingeben und die RDP-Anmeldung prüfen.
Sitzung am Windows-System sauber abmelden und danach das VPN Portal verlassen.
Mit einem Benutzer ausserhalb der Gruppe testen. Der Bookmark darf dort nicht erscheinen.
Den Testbenutzer versuchsweise aus der Policy-Gruppe entfernen und kontrollieren, ob der Zugriff nach erneuter Anmeldung verschwindet.

Erfolg bedeutet nicht nur, dass ein Desktop sichtbar wird. Der Positivbenutzer sieht genau die vorgesehenen Bookmarks, der Negativbenutzer keinen davon, MFA greift, das Zertifikat ist vertrauenswürdig, die Zielanmeldung funktioniert und die Sitzung endet auf Portal und Zielsystem nachvollziehbar.

Sitzungen und Tastatur im Browser bedienen

In RDP-, VNC-, SSH- und Telnet-Sitzungen bewegt man den Mauszeiger an den oberen Rand des entfernten Bildschirms, um die Sitzungsoptionen einzublenden. Unter Connection stehen Stop session und Suspend session zur Verfügung. Nach Suspend session setzt derselbe Benutzer die Sitzung beim nächsten Klick auf Connect im VPN Portal fort. Andere Teilnehmer einer geteilten Sitzung arbeiten währenddessen weiter; Stop session beendet sie dagegen für alle Teilnehmer.

Bei RDP- und VNC-Verbindungen lassen sich unter Keyboard Tastenkombinationen auswählen und die Tastatursprache ändern. Für eine dort aufgeführte Sprache ausser Englisch verlangt der dokumentierte Ablauf, dass die Sprache des Zielservers auf US English eingestellt ist. Diese Voraussetzung betrifft die Sprachauswahl unter Keyboard, nicht die Zwischenablage.

SSH, VNC und Dateiserver einordnen

SSH-Bookmark mit geprüftem Host Key

Für SSH wird unter Bookmarks > Add als Type SSH ausgewählt. Ein Beispiel verwendet srv-linux01.intern.example, Port 22 und den Benutzer clientless-test.

Der Public host key muss zum erwarteten Server gehören. Bei einem Linux-Ziel kann man den öffentlichen Host Key direkt an der vertrauenswürdigen Serverkonsole anzeigen und seinen Fingerprint dokumentieren:

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

Diese Befehle laufen auf dem Linux-Zielserver, nicht auf der Sophos Firewall. Verwendet der Server einen anderen Host-Key-Typ, muss der Dateiname entsprechend angepasst werden. Ein Key aus einer ungeprüften Browserwarnung oder einem beliebigen Netzscan wird nicht blind übernommen.

Der erste Befehl gibt den öffentlichen ED25519-Host-Key aus, der im Bookmark unter Public host key eingefügt wird. Der zweite Befehl zeigt nur den Fingerprint für den dokumentierten Vergleich; der Fingerprint wird nicht anstelle des Schlüssels in das Feld kopiert.

Danach wird der SSH-Bookmark vollständig angelegt:

Unter Name beispielsweise SSH-Linux-Test eintragen.
Als Type SSH auswählen.
Unter URL srv-linux01.intern.example und als Port 22 eintragen.
Unter Username clientless-test oder den vorgesehenen Zielbenutzer setzen.
Automatic login deaktiviert lassen, wenn der Benutzer das Zielpasswort selbst eingeben soll.
Den direkt am Zielsystem geprüften öffentlichen Host Key unter Public host key einfügen.
Share session deaktiviert lassen und mit Save speichern.
Den Bookmark in der Clientless-Policy unter Published bookmarks ergänzen und mit Apply speichern.
Im VPN Portal unter VPN > Clientless access connections auf Connect klicken, Zielpasswort eingeben und prüfen, ob der erwartete Terminal-Prompt erscheint. Danach die SSH-Sitzung sauber beenden.

Ohne Automatic login gibt der Benutzer das Zielpasswort beim Verbindungsaufbau ein; der Benutzername bleibt Teil des Bookmarks. Für unterschiedliche persönliche SSH-Benutzernamen braucht es deshalb getrennte Bookmarks oder einen anderen Zugriffspfad. Mit Automatic login kann SFOS Passwort oder Private Key verwenden. Privilegierte oder breit eingesetzte Private Keys sollten nicht in einem gemeinsam veröffentlichten Bookmark hinterlegt werden.

Dateiserver mit FTP, FTPS, SFTP oder SMB

Dateiserver-Bookmarks werden ebenfalls unter Remote access VPN > Clientless SSL VPN policy > Bookmarks > Add erstellt. Als Type stehen FTP, FTPS, SFTP und SMB zur Verfügung. URL enthält eine feste IP-Adresse oder einen stabilen Hostnamen; dynamische Zieladressen werden für Clientless SSL VPN nicht unterstützt. Unter Init remote folder lässt sich optional der Ordner festlegen, in dem der Benutzer nach dem Verbindungsaufbau startet.

Die Verfahren unterscheiden sich vor allem bei Transport und Zielauthentifizierung:

FTP, FTPS und SMB können mit oder ohne Automatic login verwendet werden. Ohne gespeicherte Zugangsdaten meldet sich der Benutzer nach dem Öffnen des Bookmarks am Zielsystem an. FTP überträgt unverschlüsselt und sollte für neue externe Arbeitsabläufe nicht verwendet werden.
Bei SMB lässt sich zusätzlich optional die Windows-Netzwerkdomäne eintragen, zu der Zielkonto und Zielsystem gehören, beispielsweise CORP, corp.example oder corp.example.com. Diese Beispiele werden durch die tatsächliche Domäne der eigenen Umgebung ersetzt.
FTPS schützt die FTP-Verbindung mit TLS. Zusätzlich wird unter Public host key das erwartete Serverzertifikat im .pem-Format hinterlegt. Zertifikat und Name werden direkt am verwalteten Zielsystem geprüft, nicht aus einer ungeprüften Verbindung übernommen.
SFTP verwendet SSH. Im Bookmark stehen der Zielbenutzer und entweder ein Passwort oder ein Private Key. Unter Public host key wird der verifizierte öffentliche Host Key des Servers hinterlegt. Der private Benutzerschlüssel und der öffentliche Server-Host-Key erfüllen unterschiedliche Aufgaben und dürfen nicht verwechselt werden.

Mit Automatic login werden für FTP, FTPS und SMB Benutzername und Passwort des Zielsystems im Bookmark hinterlegt. Alle berechtigten Benutzer verwenden dann diese gespeicherte Zielidentität; dafür gelten dieselben Anforderungen an minimale Berechtigungen und Rotation wie beim NLA-Beispiel. Das ist kein Credential Passthrough vom VPN Portal.

In diesem SFTP-Ablauf authentifiziert SFOS automatisch mit den im Bookmark hinterlegten Zielzugangsdaten. Der Benutzer wird nicht zur Eingabe des Zielpassworts aufgefordert; die optionale interaktive Anmeldung von SSH sowie FTP, FTPS und SMB lässt sich nicht auf SFTP übertragen.

Im Browser lassen sich bei FTP, FTPS und SFTP Dateien übertragen, Ordner anlegen und Verzeichnisse wechseln. Downloads startet SFOS ohne zusätzliche Rückfrage und speichert sie im Standard-Downloadordner des Endgeräts. Genau deshalb sollten Berechtigung, Startordner und ein Test mit nicht sensitiven Dateien vor dem produktiven Einsatz geprüft werden. Ein Dateiserver-Bookmark erzeugt kein normales Windows-Netzlaufwerk und ersetzt keine persönliche Berechtigungsprüfung am Zielserver.

Die Schaltflächen oben rechts in FTP-, FTPS- und SFTP-Sitzungen dienen zum Stoppen der Sitzung, Hochladen einer Datei, Erstellen eines Ordners und Wechseln in den übergeordneten Ordner.

Für Telnet wird unter Bookmarks > Add als Type Telnet gewählt und unter URL der feste Zielhost eingetragen; ein Port wird nur bei Abweichung vom Dienststandard gesetzt. Optional kann Share session aktiviert werden. Telnet bietet weder Transportverschlüsselung noch einen überprüfbaren SSH-Host-Key und wird deshalb nicht für neue oder untrusted Netze eingesetzt. Muss ein Altgerät kurzfristig erreicht werden, sollte der Zugriff auf eine enge Gruppe und ein isoliertes Managementziel begrenzt und anschliessend durch SSH ersetzt werden. HTTP- und HTTPS-Bookmarks gehören nicht zu den aktuell dokumentierten Clientless-Typen für SFOS 22. Für interne Webanwendungen sind je nach Schutzbedarf Web Application Firewall oder ZTNA die passendere Architektur.

Wer dieselben Ziele an mehrere Policies verteilen muss, kann unter Bookmark groups > Add eine Gruppe anlegen und mit Add new item die bestehenden Bookmarks hinzufügen. Die Policy veröffentlicht anschliessend die Gruppe statt jedes Ziel einzeln. Eine Bookmark Group erweitert keine Berechtigung am Zielsystem; sie vereinfacht nur die Zuordnung in SFOS.

Bei Anlage oder Änderung über die XML API heisst die Entität SSLBookmarkGroup. Die API-Dokumentation für SFOS 23.0 erlaubt für deren Name UTF-8-Zeichen, verbietet Kommas und behält das Maximum von 50 Zeichen bei. Die Dokumentation für SFOS 22.0 nennt bereits dieses Maximum, aber nicht die beiden zusätzlichen Zeichenregeln; daraus folgt keine Aussage über deren Durchsetzung in älteren Builds. Ein passender Beispielname ist Clientless-München, etwa <Name>Clientless-München</Name>; der Name wird an die eigene Umgebung angepasst. Nach dem API-Aufruf prüft man Statuscode und Meldung der XML-Antwort und liest die gespeicherte Gruppe zurück: Name und enthaltene Bookmarks müssen der beabsichtigten Zuordnung entsprechen. Dieser Hinweis betrifft den Gruppennamen in der API, nicht pauschal einzelne Bookmark-Namen; für die oben beschriebene UI gelten die Feldvorgaben des installierten Builds.

Typische Fehler eingrenzen

VPN Portal ist nicht erreichbar: Öffentlichen DNS-Eintrag, Port, vorgelagertes NAT, Administration > Device access und eine mögliche Port-Sharing-Wirkung prüfen.
Portal-Login schlägt fehl: Unter Authentication > Services die VPN-Portal-Authentifizierung sowie Benutzerstatus, MFA und access_server.log kontrollieren.
Clientless access connections fehlt: Der Benutzer ist keiner Clientless-Policy zugewiesen oder die Policy veröffentlicht keinen Bookmark.
Bookmark ist für den falschen Benutzer sichtbar: Policy members, Gruppenmitgliedschaften und Published bookmarks prüfen. Bei mehreren passenden Gruppen kann Clientless SSL VPN die Berechtigungen der zugehörigen Policies kombinieren. Welche Bookmarks ein realer Benutzer dadurch sieht, gehört in den Positiv- und Negativtest.
Bookmark öffnet, aber das Ziel bleibt unerreichbar: DNS-Auflösung aus Sicht der Firewall, statische Zieladresse, Routing, Zielport, Dienststatus und Host-Firewall kontrollieren.
VPN-Portal-Login funktioniert, Windows-Login nicht: Portal- und Zielanmeldung sind getrennt. Domain, Zielkonto, Passwort sowie TLS oder NLA prüfen.
NLA aktiviert Automatic login: Das ist das dokumentierte Verhalten. NLA nicht ungeplant abschalten, sondern das Konto- und Zugriffsmodell neu bewerten.
SSH meldet einen anderen Host Key: Verbindung stoppen und die Änderung direkt am Zielsystem oder über den verantwortlichen Betreiber prüfen. Ein unerwarteter Key kann auf eine Neuinstallation, ein falsches Ziel oder einen Angriff hindeuten.

Unter Diagnostics > Tools > Troubleshooting logs helfen unterschiedliche Dateien bei unterschiedlichen Phasen:

vpnportal.log für das VPN Portal;
access_server.log für Authentifizierung und Autorisierung;
clientless_access.log für Clientless-Verbindungen und den Zielaufbau;
oauth_sso_vpn.log für VPN-Portal-Anmeldungen mit SSO.

Der Testzeitpunkt, Benutzer, Bookmark und das Ziel sollten gemeinsam dokumentiert werden. Dann lassen sich Portal-, Identity- und Zielproblem in den Logs auseinanderhalten. Die allgemeine Logzuordnung und der Zugriff per Advanced Shell stehen unter Sophos Firewall Service-Logs.

Vor einer produktiven Änderung werden die bisherige Policy-Zuordnung, Device-Access-Matrix, ACL-Ausnahmen, Portalport und Zertifikatsauswahl festgehalten. Schlägt der Positivtest fehl oder sieht der Negativbenutzer einen Bookmark, wird nicht weiter geöffnet: neue Policy-Zuordnung beziehungsweise Bookmark-Veröffentlichung zurücknehmen, geänderte Portal- und ACL-Werte auf den dokumentierten Ausgangsstand setzen, neu anmelden und den Negativtest wiederholen. Zielkonten oder Host Keys werden nur separat zurückgerollt, wenn sie in diesem Change tatsächlich geändert wurden.

Betrieb und bekannte RDP-Grenzen

Clientless-Policies sollten wie andere Remote-Access-Freigaben regelmässig überprüft werden. Nicht mehr benötigte Benutzer, Bookmarks und Zielkonten werden entfernt. Gespeicherte Passwörter oder Private Keys erhalten einen Owner, ein Ablaufdatum und einen Rotationsprozess. Automatic login und Share session gehören in jede Berechtigungsprüfung.

Für die Live-Ansicht angemeldeter Remote-Benutzer öffnet man in der Admin-Konsole Current activities > Remote users. Die Verbindungen lassen sich nach Verbindungsdatum, Benutzername, Quell-IP-Adresse und zugewiesener IP-Adresse (leased IP) filtern. Mit Disconnect trennt der Administrator den ausgewählten Remote-Benutzer. Vorher Benutzer und Verbindung prüfen, da die Aktion den Zugriff unterbricht. Sie ersetzt weder das Entfernen aus der Clientless-Policy noch die saubere Abmeldung am Zielsystem; daraus folgt keine Garantie, dass alle nachgelagerten Zielsitzungen beendet sind.

Prüfen Sie vor einem Firmwarewechsel nach dem Avanet-Runbook für Firmware-Entscheide, welche Änderungen für den installierten Build und das Zielrelease gelten. Gleichen Sie dabei Clientless Access, VPN portal, RDP und das eingesetzte Authentifizierungsverfahren ab. Wiederholen Sie nach dem Upgrade den vollständigen Positiv- und Negativtest.

Bei RDP gibt es zwei aktuelle Einschränkungen, die nicht als Konfigurationsfehler behandelt werden sollten:

Die Zwischenablage wird in Clientless-RDP-Bookmarks seit SFOS 19 nicht unterstützt. Copy-and-paste zwischen lokalem Gerät und RDP-Sitzung ist deshalb kein verlässlicher Arbeitsweg.
Der Mauszeiger kann in der HTML5-RDP-Sitzung als Kreuz oder X statt als normaler Pfeil erscheinen. Sophos führt dafür derzeit keinen Workaround auf.

Wenn Zwischenablage, native RDP-Funktionen, ein breiterer Netzwerkzugriff oder persönliche Zielkonten an einem NLA-pflichtigen Server ohne gespeicherte Credentials zwingend benötigt werden, ist Clientless SSL VPN nicht die passende Abkürzung. Dann sollte der Zugriff bewusst auf Sophos Connect, RD Gateway, PAM, einen Jump Host oder ZTNA umgestellt werden.