Netzwerk & WAN
SSL-VPN
Ein SSL-VPN baut die gesicherte Verbindung über TLS auf, dieselbe Verschlüsselung wie bei HTTPS, und dient meist dem Zugang einzelner Nutzer.
- TLS-basierter Remote-Access (443)
- Clientless oder Tunnel-Modus
- DTLS für Performance
- Übergang zu ZTNA
- TLS 1.3, DTLS (UDP)
Ein SSL-VPN (genauer TLS-VPN) ist ein Remote-Access-VPN, das Verbindungsaufbau und Verschlüsselung über TLS abwickelt, in der Regel auf Port 443. Weil dieser Port als Standard-HTTPS fast überall offen ist, kommt ein SSL-VPN auch durch restriktive Netze, in denen IPsec-Ports blockiert sind.
Dieser Artikel erklärt die zwei Spielarten clientless und Tunnel-Modus, den Unterschied zwischen TLS und DTLS und warum DTLS für die Performance zählt, die Abgrenzung zu IPsec-Remote-Access, die ernste Sicherheitslage der SSL-VPN-Gateways und die Verlagerung hin zu Zero Trust.
1. Zwei Spielarten: clientless und Tunnel-Modus
SSL-VPN gibt es in zwei Ausprägungen, die sich grundlegend im Funktionsumfang unterscheiden:
| Variante | Funktionsweise und Reichweite |
|---|---|
| Clientless (Portal) | Zugriff über den Browser, das Gateway wirkt als Reverse-Proxy; gut für Webanwendungen, Webmail, RDP-Gateway. Kein beliebiger IP-Verkehr, keine nativen Desktop-Apps |
| Tunnel-Modus (Client) | ein installierter Client baut einen vollwertigen Layer-3-Tunnel; beliebiger IP-Verkehr, vergleichbar mit IPsec-Remote-Access. Full- oder Split-Tunnel konfigurierbar |
2. TLS oder DTLS: warum das zählt
Läuft der Tunnel über TLS auf TCP und transportiert darin selbst TCP-Verkehr, treffen zwei Stau- und Wiederholungsmechanismen aufeinander (TCP-over-TCP). Bei Paketverlust verstärken sie sich gegenseitig, der Durchsatz bricht ein, besonders bei VoIP, Video und interaktivem RDP. Abhilfe ist DTLS (TLS über UDP): Es übernimmt die moderne TLS-Krypto, vermeidet aber das TCP-in-TCP-Problem.
DTLS aktivieren, TLS als Fallback
Gängige Clients (etwa Cisco Secure Client) nutzen DTLS über UDP/443 für die Daten und fallen auf TLS/TCP zurück, wenn UDP blockiert ist. Für gute Performance sollte UDP/443 in den Firewalls freigegeben sein; sonst läuft alles über den langsameren TLS-Pfad.
3. Abgrenzung zu IPsec-Remote-Access
IPsec-Remote-Access (IKEv2) nutzt UDP 500/4500, die in Hotel- oder Gäste-WLANs schon mal gesperrt sind. SSL-VPN über 443 kommt fast überall durch, das ist sein praktischer Vorteil. Als Reaktion bieten manche Hersteller inzwischen IPsec über TCP/443 an. IPsec ist tendenziell performanter und stärker standardisiert, SSL-VPN punktet mit Firewall-Freundlichkeit und clientlosem Zugriff.
4. Sicherheitslage: exponierte Gateways
Ein nüchterner, wichtiger Punkt: SSL-VPN-Gateways sind öffentlich erreichbare, hochprivilegierte Systeme und gehören zu den meistangegriffenen Komponenten überhaupt. In den letzten Jahren wurden Gateways mehrerer großer Anbieter (unter anderem Fortinet, Ivanti, Citrix, Cisco ASA) wiederholt über kritische, aktiv ausgenutzte Schwachstellen kompromittiert. Die Ausnutzung von VPN- und Edge-Geräten als Ersteinstieg ist laut Branchenauswertungen stark gestiegen.
Ein lehrreiches Beispiel ist die als CitrixBleed bekannte Lücke (CVE-2023-4966): Sie erlaubte das Auslesen gültiger Sitzungs-Token aus dem Speicher, womit selbst eine vorhandene MFA per Session-Hijacking umgangen werden konnte. Einige Hersteller raten inzwischen aktiv zur Ablösung des klassischen SSL-VPN-Tunnels; Fortinet etwa hat den SSL-VPN-Tunnel-Modus mit FortiOS 7.6.3 entfernt (der clientlose Web-Modus bleibt als Agentless VPN erhalten) und nennt IPsec über TCP/443 als direkten Ersatz, ZTNA als strategischen Folgeweg.
Nicht der TLS-Tunnel an sich ist das Problem, sondern das exponierte Gateway plus der oft gewährte netzweite Vollzugriff. Konsequentes Patchen, MFA und minimale Rechte sind Pflicht, und der strategische Weg führt zu app-spezifischem Zugriff (ZTNA).
5. Authentifizierung und Posture
Zur Absicherung gehören Multi-Faktor-Authentifizierung (von BSI und NSA/CISA empfohlen), Client-Zertifikate und Posture-Checks, also die Prüfung des Endgeräts auf Patch-Stand, Festplattenverschlüsselung und Virenschutz, bevor Zugriff gewährt wird. Wie CitrixBleed zeigt, schützt MFA allein nicht, wenn das Gateway selbst kompromittiert ist, sie bleibt notwendig, aber nicht hinreichend.
6. Verlagerung zu Zero Trust
Der klassische SSL-VPN-Tunnel gewährt nach der Anmeldung oft Zugriff auf das ganze Netz, ein Widerspruch zum Prinzip der minimalen Rechte. Zero Trust Network Access (ZTNA) ersetzt das durch app-spezifischen Zugriff, der pro Sitzung neu bewertet wird; Anwendungen sind von außen nicht sichtbar. Im Rahmen von SASE wird das mit weiteren cloud-gelieferten Sicherheitsdiensten gebündelt. Viele Hersteller positionieren ZTNA ausdrücklich als Nachfolge des SSL-VPN.
7. Best Practices und typische Fehler
- Zeitnah patchen SSL-VPN-Gateways sind bevorzugte Ziele; kritische Updates sofort einspielen, exponierte Management-Oberflächen nicht ins Internet stellen.
- MFA erzwingen auf jedem Zugang, plus Posture-Checks für Endgeräte.
- Least Privilege statt Vollzugriff Zugriff auf benötigte Anwendungen begrenzen; Übergang zu ZTNA prüfen.
- DTLS aktivieren für latenz- und durchsatzkritischen Verkehr, UDP/443 freigeben.
- Standardsnah bleiben moderne TLS-Versionen (1.2/1.3) erzwingen, alte Protokolle und schwache Cipher abschalten.
8. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Firewall- und NAT-freundlich über Port 443 | Gateways sind exponierte Ziele mit hoher Schwachstellen-Dichte |
| Clientless-Zugriff auf Webanwendungen ohne Rollout | Clientless deckt nur Web-/Proxy-fähige Anwendungen ab |
| Einfacher Zugang in restriktiven Netzen | TLS-über-TCP ohne DTLS bremst latenzkritischen Verkehr |
| Granulare Steuerung je Nutzer/Anwendung (je Produkt) | Tunnel-Modus gewährt oft netzweiten Zugriff (gegen Least Privilege) |
| Breite Plattformunterstützung | Mehrere Hersteller setzen den SSL-VPN-Tunnel zugunsten von IPsec/ZTNA ab |
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
SSL-VPN im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.