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.

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

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 und Services: VPN portal 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. 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. Wenn VPN Portal und SSL VPN denselben Port und dasselbe Protokoll teilen, können sich die erreichbaren Zonen gegenseitig beeinflussen; diese Port-Sharing-Wirkung muss separat kontrolliert werden.

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

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.

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.

Weitere Bookmark-Typen

SFOS 22 dokumentiert ausserdem:

VNC für grafischen Zugriff auf entsprechend eingerichtete Linux- oder UNIX-Systeme.
FTP, FTPS, SFTP und SMB für File-Server-Zugriff im Browser. Dabei entsteht kein normales eingebundenes Netzlaufwerk. Für vertrauliche Daten sind SFTP oder FTPS dem unverschlüsselten FTP vorzuziehen.
Telnet als Terminaltyp. Weil Telnet den Transport nicht verschlüsselt, sollte es für neue Zugriffe nicht verwendet 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.

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.

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.

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.