Split Tunneling: Wann es sinnvoll ist und wann es gefährlich wird

Split Tunneling ist eine der wichtigsten – und am häufigsten missverstandenen – Entscheidungen beim VPN-Design. Gemeint ist damit, dass ein Endgerät im Remote Access VPN nicht den gesamten Datenverkehr durch den VPN-Tunnel leitet, sondern nur ausgewählte Ziele (typischerweise interne Netze oder bestimmte Anwendungen). Der restliche Traffic, vor allem Internet- und SaaS-Zugriffe, geht parallel direkt über die lokale Internetverbindung des Nutzers. Das klingt zunächst effizient: weniger Bandbreitenbedarf im Rechenzentrum, bessere Performance für Cloud-Dienste, weniger Latenz bei Videokonferenzen. Gleichzeitig kann Split Tunneling gefährlich werden, wenn es unkontrolliert eingesetzt wird: DNS-Leaks, fehlende Web- und Egress-Kontrolle, parallele Angriffswege, unsaubere Routen und ein höheres Risiko, dass kompromittierte Endgeräte die Unternehmensumgebung als Sprungbrett nutzen. Ob Split Tunneling sinnvoll ist, hängt deshalb nicht von einer pauschalen „ja/nein“-Regel ab, sondern von Ihrem Sicherheitsmodell, Ihren Compliance-Anforderungen, der Reife Ihrer Endpoint- und Cloud-Security und der Frage, welche Datenpfade Sie wirklich kontrollieren müssen. Dieser Artikel erklärt Split Tunneling verständlich und praxisnah: wie es technisch funktioniert, welche Vorteile es bietet, wann es gefährlich wird und mit welchen Best Practices Sie Split Tunneling so absichern, dass Performance und Sicherheit zusammenpassen.

Was ist Split Tunneling und wie unterscheidet es sich vom Full Tunnel?

Bei einem Remote Access VPN erhält der Client in der Regel ein virtuelles Interface sowie Routing- und DNS-Informationen. Diese bestimmen, ob Traffic über den Tunnel oder direkt ins Internet geht.

• Full Tunnel: Standardroute (0.0.0.0/0 und ggf. ::/0) zeigt in den VPN-Tunnel. Fast der gesamte Traffic – Internet, SaaS, interne Netze – läuft über den VPN-Gateway bzw. die Unternehmensinfrastruktur (oder deren cloudbasierte Security-Kontrollen).
• Split Tunneling: Nur ausgewählte Routen oder Ziele gehen durch den VPN-Tunnel (z. B. 10.0.0.0/8 oder konkrete interne Subnetze). Internet- und viele Cloud-Ziele gehen lokal.

Wichtig: Split Tunneling ist kein „Feature“, das automatisch unsicher ist. Unsicher wird es, wenn die Sicherheitskontrollen an den neuen Datenpfad nicht angepasst werden.

Warum Unternehmen Split Tunneling überhaupt einsetzen

Es gibt valide Gründe, Split Tunneling zu nutzen. Die Entscheidung ist häufig getrieben von Performance, Skalierung und Kosten – insbesondere seit Remote Work und SaaS-Nutzung stark zugenommen haben.

• Weniger Backhauling: SaaS-Traffic muss nicht ins Rechenzentrum zurückgeführt werden.
• Bessere Nutzererfahrung: Niedrigere Latenz bei Web- und Cloud-Anwendungen, stabilere Videokonferenzen.
• Entlastung der VPN-Gateways: Weniger Durchsatzlast, weniger Sessions über zentrale Appliances.
• Kostenkontrolle: Geringere Bandbreitenkosten und weniger Kapazitätserweiterungen am zentralen Standort.
• Lokale Breakouts: Standorte oder Homeoffices nutzen den jeweils besten Internetpfad statt zentraler Umwege.

Wann Split Tunneling gefährlich wird

Split Tunneling wird gefährlich, wenn es aus einem kontrollierten VPN-Zugriff einen parallelen, schwer zu überwachenden Datenpfad macht. Drei Risikobereiche sind in der Praxis besonders relevant: Kontrollverlust über Egress, DNS-Probleme und „Dual-Homing“-Effekte (gleichzeitige Verbindung in zwei Sicherheitsdomänen).

Kontrollverlust über Internet- und SaaS-Egress

Im Full-Tunnel-Modell können Unternehmen Webzugriffe zentral durch Secure Web Gateways, Proxies, DLP oder Firewall-Profile steuern. Bei Split Tunneling wandert dieser Datenverkehr ins lokale Netz des Nutzers. Ohne Ersatzkontrollen verlieren Sie Sichtbarkeit und Durchsetzung.

• Weniger Logging: Webzugriffe, Downloads und Risk Domains sind nicht mehr zentral sichtbar.
• Weniger Policy Enforcement: URL-Filter, Malware-Scanning, DLP-Regeln greifen ggf. nicht mehr.
• Mehr Schatten-IT: Unkontrollierte Cloud-Dienste können leichter genutzt werden.

DNS-Leaks und falsches Split-DNS

DNS ist einer der häufigsten Stolpersteine. Split Tunneling ohne saubere DNS-Strategie führt dazu, dass interne Domains über öffentliche Resolver aufgelöst werden oder interne Namensräume „leaken“. Das ist nicht nur ein Datenschutz-/Compliance-Thema, sondern kann auch Angreifern Informationen liefern.

• Interne Namensauflösung über öffentliche DNS: interne Hostnamen werden „nach draußen“ gefragt.
• Fehlende Auflösung interner Ressourcen: Nutzer erreichen interne Services nicht zuverlässig (Supportaufwand).
• Manipulation im lokalen Netz: Unsichere WLANs können DNS-Antworten beeinflussen, wenn kein Schutz greift.

Dual-Homing und laterale Bewegungen

Ein Remote-Client mit Split Tunneling ist gleichzeitig im Unternehmenskontext (über den VPN-Tunnel) und im lokalen Internetkontext (direkt). Wenn das Endgerät kompromittiert ist, kann der Angreifer diese Situation ausnutzen: Der Client wird zur Brücke zwischen zwei Welten.

• Angriffe aus dem lokalen Netz: Mit kompromittiertem Gerät kann ein Angreifer interne Ziele über den Tunnel ansprechen.
• Exfiltration über lokalen Egress: Daten aus dem Unternehmenskontext können über den direkten Internetpfad abfließen, ohne zentrale Kontrollen.
• Command-and-Control: C2-Verbindungen laufen direkt ins Internet und sind zentral schwerer zu erkennen.

Split Tunneling ist nicht gleich Split Tunneling: Varianten im Alltag

In der Praxis gibt es mehrere Ausprägungen, die unterschiedliche Risiken mitbringen. Wer „Split Tunneling“ sagt, sollte präzisieren, welche Variante gemeint ist.

Split per Route (klassisch)

Der VPN-Client bekommt nur interne Routen. Alles andere geht lokal. Das ist das häufigste Modell und auch das mit den klarsten Steuerungsmöglichkeiten, weil es sauber über Routing definiert ist.

Split per Anwendung oder Ziel (selektiver Tunnel)

Einige Lösungen tunnelisieren nur bestimmte Anwendungen oder definierte Domains/IPs. Das kann die Angriffsfläche reduzieren, wenn es streng umgesetzt wird, erfordert aber gute Pflege der Zieldefinitionen (z. B. SaaS-IP-Ranges ändern sich).

Split nur für SaaS (Optimierung für Cloud-Apps)

Ein typischer Kompromiss ist: Interne Ressourcen laufen über VPN, SaaS (z. B. Microsoft 365) geht lokal. Das verbessert Performance, ist aber nur sicher, wenn die SaaS-Security über andere Mechanismen durchgesetzt wird (z. B. Conditional Access, CASB/SSE, Endpoint Controls).

Entscheidungskriterien: Wann Split Tunneling sinnvoll ist

Split Tunneling kann sehr sinnvoll sein, wenn Ihr Sicherheitsmodell nicht mehr davon ausgeht, dass „alles durch das Rechenzentrum muss“, sondern wenn Sie Sicherheitskontrollen näher an den Nutzer und das Endgerät bringen.

• SaaS-first Umfeld: Der Großteil der Arbeit findet in Cloud-Anwendungen statt.
• Starke Endpoint-Security: EDR, Host-Firewall, Patch-Management, Gerätekryptografie und Härtung sind zuverlässig umgesetzt.
• Identitätsbasierte Policies: SSO, MFA und Conditional Access sind etabliert und erzwingen Zugang nach Kontext und Risiko.
• Cloud-Security-Controls: SSE/SWG/CASB oder vergleichbare Kontrollen greifen auch außerhalb des Firmennetzes.
• Klare Segmentierung: VPN-Zugänge sind rollenbasiert und führen nicht pauschal ins LAN.
• Monitoring vorhanden: DNS-/Proxy-/EDR-Telemetrie und anomale Outbounds werden erkannt.

Eine praxisnahe Orientierung zu sicheren Remote-Access- und Telework-Architekturen bietet NIST SP 800-46.

Warnsignale: Wann Split Tunneling eher gefährlich ist

Es gibt Situationen, in denen Split Tunneling zwar attraktiv wirkt, aber das Risiko deutlich erhöht – vor allem, wenn zentrale Sicherheitskontrollen sonst den Großteil der Web- und Egress-Sicherheit übernehmen.

• Keine zentralen oder clientseitigen Web-Kontrollen: Kein SWG/Proxy-Agent, keine URL-Kontrollen, keine Download-Policies.
• Unverwaltete Geräte: BYOD ohne MDM/EDR und ohne verlässliche Härtung.
• Hoher Compliance-Druck: Wenn Datenabfluss und Logging zentral nachweisbar sein müssen.
• Viele interne Legacy-Services: Breite interne Erreichbarkeit über VPN, wenig Segmentierung.
• Schwache DNS-Architektur: Keine Split-DNS-Strategie, keine zentralen Resolver, keine DNS-Sicherheitskontrollen.

Best Practices: Split Tunneling sicher umsetzen

Wenn Sie Split Tunneling einsetzen, sollten Sie es nicht als „Performance-Schalter“ betrachten, sondern als Sicherheitsdesign mit klaren Leitplanken.

Least Privilege für VPN-Routen und Ziele

• Nur notwendige interne Netze: Keine Vollkopplung; nur Subnetze, die der Nutzer wirklich braucht.
• Rollenprofile: Unterschiedliche VPN-Profile für Standardnutzer, Admins und Dienstleister.
• Adminzugriff getrennt: Administrative Zugriffe über Jump Host oder spezielle Admin-Zone.

DNS-Strategie sauber definieren

• Split-DNS: Interne Domains werden über interne Resolver aufgelöst, externe Domains über definierte Resolver (je nach Policy).
• DNS-Leaks verhindern: Interne Domain-Anfragen dürfen nicht über öffentliche Resolver gehen.
• DNS-Security: DNS-Filter/Schutz (z. B. Blocklisten, Policy) zentral oder clientseitig durchsetzen.

Web- und SaaS-Sicherheit über SSE/SWG oder Endpoint Controls absichern

Split Tunneling ist nur dann nachhaltig, wenn Webzugriffe außerhalb des VPN-Tunnels trotzdem kontrolliert sind. Typische Optionen:

• Clientseitiges SWG: Agent/Client, der Webtraffic zum Security-PoP leitet.
• CASB/DLP: Kontrolle von Uploads und Freigaben in SaaS, unabhängig vom Netzpfad.
• Conditional Access: Zugriff auf SaaS nur von compliant Geräten, mit MFA und risikobasierten Regeln.

Endpoint-Härtung verpflichtend machen

• EDR/XDR: Erkennung und Isolation kompromittierter Geräte.
• Host-Firewall: Lokale Regeln, die unnötige eingehende Verbindungen blocken.
• Patch-Management: Aktualität von OS und Browser/Clients als Basisanforderung.
• Geräteverschlüsselung: Schutz bei Verlust/Diebstahl, besonders bei mobilen Geräten.

Traffic- und Datenabflusskontrolle nicht vergessen

Bei Split Tunneling kann Exfiltration über den lokalen Internetpfad erfolgen. Deshalb sollten Sie zusätzliche Signale etablieren:

• Proxy/SWG-Logs: Wenn ein SSE/SWG genutzt wird, müssen Events zentral auswertbar sein.
• EDR-Network-Telemetrie: Ungewöhnliche Outbounds, neue Ziele, hohe Uploads.
• DNS-Logs: NXDOMAIN-Spikes, DGA-Muster, neue Domains.

Split Tunneling und Admins: Warum privilegierte Zugriffe eine Sonderrolle haben

Für Administratoren und privilegierte Konten gelten strengere Regeln. Ein kompromittierter Admin-Client kann kritische Systeme unmittelbar gefährden. Deshalb ist es häufig sinnvoll, Admin-Zugriffe anders zu behandeln als Standard-User-Zugriffe.

• Phishing-resistente MFA: Security Keys/Passkeys statt nur Push oder TOTP.
• Separate Admin-Workstations: Admin-Arbeit nur von dedizierten, gehärteten Geräten.
• Restriktive VPN-Routen: Admins bekommen nicht „mehr Netz“, sondern gezielten Zugang über Management-Pfade.
• Session-Logging: Jump Hosts/Bastions mit nachvollziehbarer Session-Aufzeichnung.

Split Tunneling in hybriden Umgebungen: Cloud, SaaS und Standortnetze

In hybriden Umgebungen ist Split Tunneling oft ein Enabler für bessere Performance, weil SaaS und Cloud-Ziele nicht mehr durch das zentrale Rechenzentrum müssen. Gleichzeitig steigt die Bedeutung von Identität und Cloud-Policies.

• SaaS-Zugriff über Identity: MFA, Conditional Access, Gerätestatus sind entscheidend.
• Cloud-native Logs: Audit-Logs und Access-Logs ergänzen Netzwerk- und Endpoint-Telemetrie.
• Standortkopplungen getrennt betrachten: Site-to-Site (IPSec) ist ein anderes Thema als Remote Split Tunnel.

Typische Fehler in der Praxis (und wie Sie sie vermeiden)

• Split Tunnel „an“ ohne Sicherheitsersatz: Zentrale Web-/Egress-Kontrollen fallen weg, ohne dass SSE/Endpoint nachzieht.
• Falsche DNS-Konfiguration: Interne Domains leaken oder lösen nicht auf; Supportaufwand und Sicherheitsrisiko.
• Zu breite interne Routen: Split Tunnel wird zur „Teil-Vollkopplung“ und erhöht laterale Bewegung.
• Keine Segmentierung der VPN-Zone: VPN-Clients landen im gleichen Netz wie interne Clients/Server.
• Keine Monitoring-Use-Cases: Outbound-Anomalien und Exfiltration werden nicht erkannt.
• Ausnahmen ohne Ablaufdatum: Temporäre Freigaben werden dauerhaft und unterlaufen das Modell.

Praktische Entscheidungslogik: Ein einfacher Fragenkatalog

• Wo liegen die meisten Ihrer Anwendungen? Intern/On-Premises oder SaaS/Cloud?
• Wie stark sind Ihre Endgeräte kontrolliert? MDM, EDR, Patch-Stand, Host-Firewall.
• Wie setzen Sie Web-Policies durch? Zentraler Proxy/SWG oder clientseitige Security?
• Welche Compliance-Anforderungen gibt es? Logging, DLP, Nachvollziehbarkeit, Datenabflusskontrolle.
• Wie ist Ihr Zonenmodell? Gibt es eine dedizierte VPN-Zone mit restriktiven Flows?
• Wie wird DNS gelöst? Split-DNS, Resolver-Policy, Schutz vor DNS-Leaks.

Checkliste: Split Tunneling sicher betreiben

• VPN-Routen sind minimal und rollenbasiert (Least Privilege statt großer Netzkopplung)
• DNS-Strategie ist dokumentiert und leak-sicher (Split-DNS, zentrale Resolver, DNS-Security)
• Web-/SaaS-Traffic wird außerhalb des Tunnels trotzdem kontrolliert (SSE/SWG/CASB/Conditional Access)
• Endgeräte sind gehärtet und compliant (MDM, EDR, Patch-Management, Host-Firewall, Verschlüsselung)
• VPN-Clients landen in einer dedizierten Zone, interne Flows sind restriktiv segmentiert
• Privilegierte Zugriffe sind gesondert abgesichert (starke MFA, Jump Host, Admin-Workstations)
• Monitoring-Use-Cases existieren (neue Outbound-Ziele, Datenmengen-Spikes, DNS-Anomalien)
• Ausnahmen sind dokumentiert, befristet und werden regelmäßig rezertifiziert

Weiterführende Informationsquellen

• NIST SP 800-46: Telework, Remote Access and BYOD
• NIST SP 800-63B: Digitale Authentifizierung und Faktoren
• NIST SP 800-207: Zero Trust Architecture
• BSI: IT-Grundschutz und Empfehlungen zu Remote Access und Netzwerksicherheit

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.