SSL-VPN Troubleshooting: Login klappt, aber keine Ressourcen erreichbar

SSL-VPN Troubleshooting wird besonders dann knifflig, wenn der Login sauber funktioniert, die Verbindung im Client als „connected“ angezeigt wird und sogar eine VPN-IP vergeben wurde – aber trotzdem keine internen Ressourcen erreichbar sind. In diesem Szenario ist die Authentifizierung nicht das Problem, sondern der Datenpfad: Routing, Split-Tunneling, Zugriffsrichtlinien, DNS, lokale Firewalls oder ein falsches Netzwerkprofil verhindern, dass Traffic korrekt ins Unternehmensnetz gelangt oder dass Antworten den Weg zurückfinden. Typische Symptome sind Timeouts auf interne Webanwendungen, RDP/SSH-Verbindungen, die hängen bleiben, „DNS geht nicht“, nur bestimmte Subnetze funktionieren oder nur Name-zu-IP-Auflösung klappt, während die Verbindung selbst nicht zustande kommt. Häufig verschärfen moderne Umgebungen die Lage: Endpoint-Security-Agenten, Always-on VPN, ZTNA-Komponenten, Cloud-DNS, IPv6, Proxy-Autokonfiguration oder überlappende RFC1918-Netze im Homeoffice. Dieser Artikel liefert einen praxiserprobten Leitfaden, um genau diese Klasse von Problemen systematisch einzugrenzen. Sie arbeiten dabei vom Client nach innen: erst prüfen Sie, ob der VPN-Client den Traffic überhaupt „übernimmt“, dann ob der VPN-Gateway ihn akzeptiert und korrekt routet, und schließlich ob Zielnetze, Firewalls und DNS den Zugriff erlauben. So kommen Sie schnell von „Login klappt, aber nichts geht“ zu einem belastbaren Root Cause – und zu einer Lösung, die dauerhaft stabil bleibt.

Das Fehlerbild richtig einordnen: Auth ist ok, Data Plane ist kaputt

Wenn der Login klappt, sind diese Komponenten grundsätzlich funktionsfähig: Benutzerkonto/SSO, MFA, Zertifikate, TLS-Handshakes, Portalzugang und meist auch die grundlegende Client-Kommunikation zum Gateway. Die Fehler liegen dann typischerweise in einem dieser Bereiche:

• Client-Routing: Der Client schickt den Traffic nicht in den VPN-Tunnel (Split-Tunnel falsch, Route fehlt, falsches Interface-Prioritätsverhalten).
• VPN-Policy/Access-Control: Der Gateway erlaubt zwar den Login, aber nicht den Zugriff auf bestimmte Netze/Ports (Policy, Gruppenmapping, Posture-Check).
• DNS: Namen werden falsch aufgelöst oder interne DNS-Server sind nicht erreichbar (DNS-Server nicht gepusht, DNS-Suffix fehlt, DoH umgeht Unternehmens-DNS).
• Rückweg/Asymmetrie: Der Hinweg geht über VPN, der Rückweg nicht (fehlende Rückroute, NAT/Firewall, unterschiedliche Gateways).
• MTU/Fragmentierung: Kleine Pakete gehen, größere hängen (Tunnel-Overhead, PMTUD kaputt).
• Lokale Endpunkt-Firewall/EDR: Der Client blockt Verbindungen oder beeinflusst die Adapterpriorität.

Vorbereitung: Minimaltest definieren und Scope festzurren

Bevor Sie „alles“ prüfen, definieren Sie einen reproduzierbaren Testfall. Ohne reproduzierbaren Test wird die Fehlersuche beliebig.

• Eine Ressource: z. B. ein internes Webziel (TCP/443) oder ein Ping zum Default Gateway im Zielnetz.
• Eine Richtung: Client → Ressource; später testen Sie den Rückweg explizit.
• Ein Clienttyp: Windows oder macOS, und möglichst ein zweites Gerät zum Vergleich (A/B-Test).
• Ein Zeitfenster: Notieren Sie Zeitstempel, um Logs am Gateway/Firewall zu korrelieren.

Schritt 1: Übernimmt der VPN-Client den Traffic überhaupt?

Die häufigste Ursache ist banal: Der Client ist verbunden, aber der Traffic wird nicht über den Tunnel geroutet. Das passiert besonders oft bei Split-Tunneling, bei mehreren aktiven Netzadaptern oder bei fehlerhaften Routen.

Routing und Adapterpriorität prüfen

• Hat der VPN-Adapter eine gültige IP und ggf. ein VPN-internes Gateway?
• Welche Routen wurden nach dem Connect hinzugefügt (Zielnetze, Default Route, Metrik/Priorität)?
• Ist Split-Tunnel aktiv? Wenn ja: sind alle benötigten Prefixe enthalten?
• Gibt es konkurrierende VPNs (z. B. Always-on, WireGuard, Corporate Agent), die Routen überschreiben?

Praxis-Indiz: Wenn Internet weiterhin normal funktioniert, aber interne Ziele nicht, ist Split-Tunnel oder Routing-Push oft der Hauptverdächtige. Wenn hingegen alles (auch Internet) „komisch“ wird, kann eine Default-Route über den Tunnel gesetzt sein, aber DNS oder Policy stimmt nicht.

Split-Tunneling als Fehlerquelle

• Zu enge Split-Routen: Nur ein Subnetz wurde gepusht, aber die App liegt in mehreren Netzen (App + DB + Identity).
• Falsche Summaries: Eine zu grobe Summary kollidiert mit lokalen Netzen (z. B. 10.0.0.0/8).
• Falsche Priorität: Route existiert, aber hat eine ungünstige Metrik, sodass ein anderes Interface gewinnt.

Schritt 2: DNS im SSL-VPN: Wenn Namen falsch oder gar nicht auflösen

Viele „keine Ressourcen erreichbar“-Tickets sind in Wahrheit DNS-Probleme. Nutzer testen oft nur „intranet.company.local“ und denken, die Verbindung sei kaputt. Dabei wäre die IP erreichbar – wenn man sie direkt anpingt oder via IP aufruft.

Typische DNS-Fehlerbilder

• Interne Namen lösen nicht auf: VPN pusht keinen DNS-Server oder keinen DNS-Suffix/Search Domain.
• Interne Namen lösen auf öffentliche IPs: Split-DNS/Split-Horizon greift nicht, weil der Client den falschen Resolver nutzt.
• DNS-Server ist gesetzt, aber nicht erreichbar: Route zum DNS fehlt (häufig bei Split-Tunnel), oder Firewall blockt UDP/TCP 53.
• DoH/Private DNS umgeht Unternehmens-DNS: Browser nutzt DNS over HTTPS und ignoriert Systemresolver.

Pragmatischer Test

• Testen Sie die Ressource einmal per Hostname und einmal per IP.
• Wenn IP geht, Name nicht: DNS/Suffix/Resolver-Kette prüfen.
• Wenn Name auf eine unerwartete IP zeigt: Split-Horizon/Conditional Forwarding/Resolver-Priorität prüfen.

DNS-Grundlagen sind in RFC 1035 beschrieben; für TLS-abhängige Webzugriffe ist relevant, dass falsche DNS-Antworten zu TLS-Zertifikatsfehlern führen können.

Schritt 3: Policy und Zugriffsrechte: Login ≠ Zugriff

Bei SSL-VPNs ist es üblich, dass der Login (Authentifizierung) getrennt von der Autorisierung ist. Der Nutzer kann sich anmelden, bekommt eine VPN-IP, aber sein Policy-Set erlaubt nur bestimmte Ressourcen oder gar keine (z. B. Quarantäne/Onboarding).

Häufige Policy-Fallen

• Falsches Gruppenmapping: User landet nach SSO/MFA in der falschen Gruppe (oder Default-Gruppe ohne Zugriff).
• Posture/Compliance nicht erfüllt: Endpoint-Checks (AV, Disk Encryption, OS-Version) schlagen fehl → „restricted“ Profil.
• Zu enge Network Objects: Policy erlaubt nur ein Subnetz, die Anwendung nutzt aber weitere Netze (IdP, DNS, NTP, API-Gateways).
• Port-/Service-Limits: ICMP erlaubt, aber TCP/443 nicht; oder Web geht, aber RDP/3389 ist gesperrt.

Wie Sie Policy-Probleme schnell bestätigen

• Gateway-Logs prüfen: Welche Policy wurde zugewiesen? Welche Regeln matchen?
• Hit-Counter/Log-Entries: Gibt es Deny-Logs für den Testverkehr?
• A/B-Test: Funktioniert derselbe Zugriff mit einem anderen Userprofil (z. B. Admin-Gruppe)?

Schritt 4: Der Rückweg zählt: Asymmetrisches Routing und fehlende Rückrouten

Ein SSL-VPN kann perfekt aufgebaut sein, aber Antworten kommen nicht zurück, weil das interne Netzwerk die VPN-Client-IP nicht kennt oder weil der Rückweg über ein anderes Gateway geht. Das ist besonders häufig in größeren Netzen mit mehreren Firewalls, VRFs oder Standorten.

Typische Rückweg-Probleme

• Keine Route zum VPN-Client-Pool: Interne Router wissen nicht, dass 10.250.0.0/16 (VPN-Pool) hinter dem VPN-Gateway liegt.
• Asymmetrie durch mehrere Internet-Edges: Hinweg über Gateway A, Rückweg über Gateway B → stateful Drops.
• NAT-Konflikte: VPN-Gateway NATtet Clients, interne Systeme erwarten aber originale Client-IPs (oder umgekehrt).
• Policy Routing im Core: Bestimmte Netze werden „forced“ über eine andere Firewall geleitet.

Beweisführung im Incident

• Wenn möglich, testen Sie den Zugriff aus dem internen Netz zurück zur VPN-Client-IP (Rückping/Reverse Test).
• Prüfen Sie interne Routingtabellen auf den VPN-Pool-Prefix.
• Korrelieren Sie Firewall-Logs: sehen Sie die Anfrage am Zielserver, aber keine Antwort am VPN-Gateway?

Schritt 5: MTU/PMTUD: Login ok, aber Apps hängen oder Timeouts bei größeren Antworten

SSL-VPNs kapseln Traffic (TLS/DTLS/UDP-Encapsulation je nach Produkt) und reduzieren dadurch die effektive MTU. Viele Probleme zeigen sich erst, wenn größere Pakete übertragen werden: Downloads, HTTPS-Responses, RDP-Grafikdaten, Dateiübertragungen oder bestimmte API-Antworten.

Typische MTU-Symptome

• Kleine Pings funktionieren, größere Payloads hängen.
• Webseiten laden teilweise, Login/SSO hängt beim Redirect oder POST.
• Viele TCP Retransmissions im Client-Capture.

• Fix-Ansätze: MTU am VPN-Interface anpassen, MSS-Clamping auf dem Gateway, ICMP sinnvoll erlauben, damit PMTUD funktioniert.

Hintergrundwissen zu Path MTU Discovery finden Sie in RFC 1191.

Schritt 6: Lokale Client-Faktoren: Firewall, EDR, Proxy, IPv6

Wenn nur einzelne Nutzer betroffen sind, liegt es häufig am Endgerät. Gerade EDR- und DLP-Produkte können Netzwerkverkehr filtern oder VPN-Adapter beeinflussen. Auch Proxies und IPv6 sind häufige Störenfriede.

Lokale Firewall/EDR

• Blockiert die lokale Firewall den Zugriff auf interne IPs (z. B. neue Netzprofile „Public“)?
• Erzwingt der EDR ein Proxying/Inspection, das über VPN nicht funktioniert?
• Ändert ein Agent die DNS- oder Routing-Einstellungen nach dem VPN-Connect?

Proxy und PAC-Dateien

• Wenn der Browser über Proxy/PAC arbeitet, kann interner Traffic fälschlich an einen externen Proxy gehen.
• Split-Tunnel + Proxy führt oft zu „geht im Browser nicht, aber per IP/Tool geht es“.

IPv6-Preferencing

• Clients bevorzugen IPv6, aber der VPN-Tunnel transportiert nur IPv4.
• DNS liefert AAAA-Records, der Pfad ins IPv6-Netz fehlt → Timeouts.
• Fix: IPv6-Strategie klären (entweder sauber durch den Tunnel oder kontrolliert deaktivieren/steuern), AAAA-Verhalten prüfen.

Häufige Root Causes im Überblick: Die „Top 12“ aus der Praxis

• Split-Tunnel enthält nicht alle benötigten Prefixe (App funktioniert nur teilweise).
• DNS-Server oder DNS-Suffix wird nicht gepusht (Hostname-Auflösung kaputt).
• VPN-Pool hat keine Rückroute im internen Netz (Rückweg fehlt).
• User landet im falschen Policy-Profil (Login ok, aber „no access“).
• Posture-Check schlägt fehl und setzt Quarantäne-Policy.
• Firewall-Regel erlaubt nur bestimmte Ports, nicht aber Ephemeral/Backend-Kommunikation.
• Asymmetrisches Routing durch mehrere Gateways/Firewalls.
• NAT-Konflikt oder Overlap mit Home-Netz (z. B. 192.168.0.0/24 lokal wie intern).
• MTU/PMTUD-Probleme (große Antworten hängen).
• Proxy/PAC lenkt internen Traffic falsch.
• IPv6 bevorzugt, aber Tunnel ist IPv4-only.
• Receiver/Serverseitige ACLs blocken VPN-Pool (z. B. „nur LAN-IP-Ranges erlaubt“).

Beweise sammeln: Welche Logs und Daten im Incident am meisten bringen

Gerade bei SSL-VPN-Problemen spart strukturierte Beweisführung viel Zeit, weil Sie damit Teams (Netzwerk, Security, Client, Applikation) schnell auf den richtigen Fehlerbereich ausrichten.

• Clientseitig: Routing-Tabelle nach Connect, DNS-Server/Suffix, VPN-IP, Test per IP vs. Hostname.
• Gateway: Zugewiesene Policy, Session-Logs, Zugriffsdrops, NAT-Übersetzungen, Bytes/Packets pro Session.
• Firewall/Core: Route zum VPN-Pool, Deny-Logs, State-/Asymmetrie-Hinweise.
• Server: Kommen Requests an? Antworten raus? Lokale Firewall erlaubt VPN-Pool?
• Optional Capture: Kurzer Mitschnitt am Client oder Gateway, um Retransmissions/MTU/Handshake-Probleme sichtbar zu machen.

Best Practices: SSL-VPN so designen, dass „Login aber kein Zugriff“ selten wird

• VPN-Pool routbar machen: Rückrouten zentral verteilen (Core, Firewalls, segmentübergreifend).
• Split-Tunnel sauber pflegen: Prefix-Listen versionieren, Changes reviewen, App-Abhängigkeiten (IdP, DNS, API) berücksichtigen.
• DNS-Strategie definieren: interne Resolver, Suffixe, Split-DNS; DoH-Policy bewusst steuern.
• Policies transparent halten: klare Gruppen, nachvollziehbare Posture-Regeln, Quarantäne sichtbar kommunizieren.
• MTU standardisieren: MSS-Clamping/MTU-Defaults dokumentieren, ICMP sinnvoll erlauben.
• Diag-Ziele bereitstellen: interne Test-IP und Test-Hostname (Ping/HTTPS), um Probleme schnell zu reproduzieren.
• Monitoring: Alerts auf „Connected Sessions ohne Throughput“, Policy-Denies, DNS-Failures, Route-Drift.

Outbound-Links zur Vertiefung

• RFC 8446: TLS 1.3 (Grundlage vieler SSL-VPN-Transporte)
• RFC 1035: DNS (Resolver-Verhalten, NXDOMAIN/Timeouts)
• RFC 1918: Private IPv4-Adressräume (Overlap-Probleme im Homeoffice)
• RFC 1191: Path MTU Discovery (MTU-Probleme in Tunneln)
• Wireshark Dokumentation: Paketfluss, Retransmissions und MTU-Probleme sichtbar machen

Checkliste: SSL-VPN Troubleshooting, wenn Login klappt, aber keine Ressourcen erreichbar sind

• Testfall definieren: eine Ressource, ein Port, eine Quelle; Hostname- und IP-Test getrennt durchführen.
• Client prüfen: VPN-IP vorhanden, VPN-Adapter aktiv, Routingtabellen/Prefixe korrekt, Split-Tunnel vollständig, Adapterpriorität passt.
• DNS prüfen: DNS-Server und Suffix gepusht? Interne Namen lösen korrekt auf? DoH/Proxy beeinflusst Auflösung?
• Policy prüfen: Welches Profil/Gruppe wurde zugewiesen? Posture-Check ok? Gibt es Deny-Logs für Zielnetz/Port?
• Rückweg prüfen: Route zum VPN-Pool im internen Netz vorhanden? Asymmetrie ausgeschlossen? Stateful Firewall/NAT kompatibel?
• Subnetz-/Server-ACLs prüfen: Zielsysteme erlauben Zugriffe aus dem VPN-Pool (nicht nur aus LAN-Subnets)?
• MTU prüfen: Wenn große Payloads hängen, MSS/MTU anpassen, PMTUD/ICMP-Handling prüfen.
• Client-Faktoren prüfen: lokale Firewall/EDR, Proxy/PAC, konkurrierende VPNs, IPv6-Preferencing.
• Beweise sammeln: Gateway-Session-Stats, Policy-Hits, Firewall-Logs, Routing-Exports, optional kurzer Mitschnitt.
• Fix verifizieren: identischer Testfall, Vorher/Nachher dokumentieren, Änderungen in Templates/IaC und Betriebshandbuch übernehmen.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.