Split Tunneling & IPv4 ist eines der Themen, bei denen sich Performance und Sicherheit unmittelbar gegenüberstehen – und bei denen Routing-Details darüber entscheiden, ob eine VPN-Lösung sauber funktioniert oder im Alltag ständig Probleme macht. Beim Split Tunneling wird nicht der gesamte Datenverkehr eines VPN-Clients durch den Tunnel geleitet, sondern nur der Traffic zu definierten internen Netzen (oder umgekehrt: nur bestimmter Traffic wird ausgenommen). Das spart Bandbreite im Unternehmensnetz, reduziert Latenz für Internetdienste und kann Cloud-Anwendungen deutlich schneller machen. Gleichzeitig erhöht Split Tunneling die Komplexität: Plötzlich muss der Client zwei „Wege ins Netz“ parallel nutzen, und es hängt von Routen, Metriken, DNS-Auflösung und Sicherheitsrichtlinien ab, welcher Weg für welches Ziel verwendet wird. Besonders in IPv4-Umgebungen entstehen dabei häufig typische Fehlerbilder: interne Ziele sind nicht erreichbar, einzelne Anwendungen verbinden sich am VPN vorbei, lokale Heimnetz-Adressbereiche kollidieren mit Firmennetzen oder DNS löst zwar korrekt auf, aber die Pakete nehmen den falschen Pfad. Dieser Artikel erklärt verständlich, was Split Tunneling technisch bedeutet, welche Routing-Regeln dabei entscheidend sind, wie du Adresskollisionen vermeidest und welche Best Practices sich in der Praxis bewährt haben – für Einsteiger ebenso wie für erfahrene Admins.
Was ist Split Tunneling – und was bedeutet das fürs IPv4-Routing?
Split Tunneling beschreibt ein Routing-Verhalten auf dem Client: Der VPN-Tunnel ist nur für bestimmte Ziele zuständig, während anderer Traffic weiterhin das lokale Standard-Gateway (z. B. Heimrouter, Hotspot, Firmennetz ohne VPN) nutzt. Technisch bedeutet das: Der VPN-Client installiert (oder verändert) IPv4-Routen auf dem Endgerät.
- Full Tunnel: Standardroute (0.0.0.0/0) zeigt durch den VPN-Tunnel; praktisch alles geht über das Unternehmensnetz.
- Split Tunnel: Nur definierte Präfixe (z. B. 10.60.0.0/16) werden über den Tunnel geroutet; Internet bleibt lokal.
- Selective Split: Sonderformen, bei denen z. B. nur Unternehmens-SaaS oder nur bestimmte Applikationen über den Tunnel gehen.
Die Grundlage dafür ist classless Routing mit CIDR-Präfixen, wie es in RFC 4632 beschrieben ist. Für private IPv4-Bereiche, die in VPN-Szenarien typischerweise geroutet werden, ist RFC 1918 relevant.
Routing-Mechanik auf dem Client: Longest Prefix Match und Metriken
Damit Split Tunneling funktioniert, muss der Client eindeutig entscheiden können, welche Route für ein Ziel gilt. Dabei greifen zwei zentrale Mechanismen:
- Longest Prefix Match: Die spezifischste Route gewinnt (z. B. /24 vor /16 vor /0).
- Route-Metrik: Wenn mehrere Routen gleich spezifisch sind, entscheidet die Metrik (je nach Betriebssystem/VPN-Client).
Ein Split-Tunnel-Setup ist dann stabil, wenn die VPN-Routen spezifisch genug sind, sodass interner Traffic zuverlässig über den Tunnel läuft, während Internetziele die lokale Standardroute nutzen.
Beispiel: Typisches Split-Tunnel-Routing
- VPN installiert: 10.60.0.0/16 → Tunnel
- Lokales Netz: 192.168.1.0/24 → lokales Interface
- Default: 0.0.0.0/0 → lokales Gateway (Internet bleibt lokal)
Wenn ein Ziel 10.60.10.50 angesprochen wird, gewinnt die /16-Route in den Tunnel. Für 8.8.8.8 gilt nur die Default Route, also lokal.
Warum Split Tunneling oft „komisch“ wirkt: typische Fehlerbilder
Split Tunneling macht Fehler sichtbarer, die bei Full Tunnel manchmal „verdeckt“ bleiben. Die häufigsten Symptome sind:
- Interne Ziele sind nicht erreichbar, obwohl VPN „verbunden“ ist (fehlende oder falsche Präfixroute).
- Einzelne Anwendungen umgehen den Tunnel (z. B. weil nur IP-Präfixe getunnelt werden, aber die App nutzt andere Ziele).
- DNS stimmt, Pfad stimmt nicht: Name löst auf interne IP auf, aber Route zeigt lokal.
- Nur manche Nutzer betroffen: abhängig vom lokalen Heimnetz (Adresskollisionen).
- „Flapping“: intermittierende Erreichbarkeit durch konkurrierende Routen oder wechselnde Metriken (WLAN/LAN gleichzeitig).
Der Klassiker: Adresskollisionen mit Heimnetzen und warum Split Tunnel das verschärft
Adresskollisionen sind einer der häufigsten Gründe, warum Split Tunneling im Homeoffice scheitert. Wenn ein Mitarbeiter zu Hause 192.168.1.0/24 nutzt und das Unternehmen denselben Bereich intern, kann der Client nicht sinnvoll unterscheiden, ob 192.168.1.50 lokal oder über VPN gemeint ist. In Split-Tunnel-Szenarien wird häufig der lokale Pfad bevorzugt, weil die Route direkter oder die Metrik niedriger ist.
Beispiel: Kollision mit 192.168.1.0/24
- Heimnetz: 192.168.1.0/24
- Firmennetz (alt): 192.168.1.0/24
- Folge: Interne Systeme im gleichen Bereich sind über VPN nicht erreichbar oder landen im Heimnetz.
Die nachhaltige Lösung ist ein Unternehmensadressplan, der solche typischen Heimnetze vermeidet. Private Bereiche sind in RFC 1918 festgelegt, aber wie du sie nutzt, ist Design- und Governance-Frage.
Split Tunneling sauber planen: Welche IPv4-Präfixe werden getunnelt?
Die wichtigste Konfigurationsentscheidung lautet: Welche Ziele sollen durch den Tunnel? In der Praxis gibt es drei verbreitete Modelle:
- Nur interne RFC1918-Netze: Tunnel enthält ausschließlich Unternehmenspräfixe (z. B. 10.64.0.0/12).
- Interne Netze + ausgewählte Cloud-/SaaS-Ziele: bestimmte öffentliche IP-Ranges (z. B. für Security-Inspection oder Compliance) werden zusätzlich getunnelt.
- Ausnahmebasiert: Full Tunnel, aber definierte Ziele (z. B. Videokonferenzen) werden lokal geroutet.
Best Practice: „So wenig wie möglich, so viel wie nötig“
Ein häufiges Missverständnis ist, dass Split Tunneling automatisch „mehr Performance“ bedeutet. Wenn du aber zu viele Präfixe durch den Tunnel schickst oder zu viele Ausnahmen definierst, entsteht Komplexität ohne echten Nutzen. Sinnvoll ist Split Tunneling vor allem dann, wenn:
- Internet-Traffic nicht zentral inspiziert werden muss,
- Bandbreite am Unternehmens-Gateway knapp ist,
- Cloud-Anwendungen direkt (lokal) besser funktionieren,
- du klare Policies und Monitoring für den getunnelten Traffic hast.
DNS und Split Tunneling: Der unterschätzte Stolperstein
Routing ist nur die halbe Wahrheit. Viele Probleme entstehen, weil DNS nicht zum Routing-Modell passt. Wenn ein Client bei aktivem Split Tunnel weiterhin lokale DNS-Resolver nutzt, kann es passieren, dass interne Namen nicht auflösbar sind oder – schlimmer – auf falsche Ziele zeigen.
- Interne Zonen: sollten über Unternehmens-DNS auflösbar sein.
- Split DNS: je nach Domain wird ein anderer Resolver genutzt (intern vs. extern).
- Search Suffix: kann helfen, ist aber kein Ersatz für korrektes Resolver-Routing.
DNS-Grundlagen sind in RFC 1034 und RFC 1035 beschrieben. Für den VPN-Kontext ist wichtig: DNS und Routing müssen denselben „Wahrheitsraum“ abbilden.
Typische DNS-Fallen bei Split Tunnel
- Interne Namen lösen auf private IPs auf, aber der Client hat keine passende Tunnel-Route.
- Öffentliche Nameserver liefern andere Antworten als interne (Split-Horizon), was bei falschem Resolver zu Fehlern führt.
- DNS-Leaks: Anfragen zu internen Domains gehen über lokale Resolver – problematisch für Datenschutz und Security.
Security-Perspektive: Split Tunneling als Risiko – und wie du es kontrollierst
Der Kernkonflikt: Split Tunneling reduziert den Einfluss der zentralen Sicherheitsinfrastruktur, weil ein Teil des Traffics nicht durch Unternehmensfirewalls, Proxies oder Inspection-Systeme läuft. Dadurch entstehen Risiken, die du bewusst mitigieren solltest.
- Risk: Gerät ist gleichzeitig im Internet und im Firmennetz erreichbar („dual-homed“).
- Risk: Malware-Traffic könnte lokal laufen, während interne Zugriffe über VPN möglich sind.
- Risk: Security-Logging und DLP decken nur den getunnelten Anteil ab.
Praktische Gegenmaßnahmen
- Endpoint-Security: EDR/AV, Host-Firewall, Disk Encryption, Hardening.
- Zero-Trust-Prinzipien: Applikationszugriff nach Identität/Device-Posture statt „IP ist intern“.
- Segmentierung: VPN-Client-Pools in eigene Zonen, restriktive Zugriffe.
- Monitoring: klare Sichtbarkeit in Logs für VPN-Client-Pools und kritische Ziele.
Als Orientierung für VPN-Security (insbesondere IPsec) ist NIST SP 800-77r1 eine etablierte Referenz.
Routing-Best Practices: So bleibt Split Tunnel stabil
Split Tunneling steht und fällt mit sauberer Routenvergabe. Die folgenden Best Practices helfen, das Routing vorhersehbar zu halten:
- Klare Präfixlisten: Nur notwendige interne Netze in den Tunnel; keine „wildcard“-Zusammenfassungen ohne Verifikation.
- Summary-fähiger Adressplan: Standort- und Zonenblöcke zusammenhängend planen, damit du wenige Präfixe tunneln musst.
- Keine Overlaps: Unternehmensadressräume so wählen, dass Heimnetze selten kollidieren (typische 192.168.0/24 vermeiden).
- VPN-Client-Pool getrennt: eigener Adressbereich für Remote Clients, damit Policies sauber bleiben.
- Metriken kontrollieren: sicherstellen, dass Tunnelrouten nicht „unter“ lokale Routen fallen.
- Testfälle definieren: interne DNS-Zonen, Kernapplikationen, Admin-Zugriffe, Druck, Fileservices, VoIP.
Adressplan-Hebel: Weniger Routen durch Summarization
Je besser du Adressräume strukturierst, desto weniger Präfixe musst du im Split Tunnel verteilen. Beispiel: Wenn alle internen Standortnetze als zusammenhängende Regionenblöcke geplant sind, kannst du statt 80 Einzelnetzen vielleicht 5–10 Summaries tunneln. Das reduziert Fehler und vereinfacht Wartung.
Split Tunnel vs. Full Tunnel: Wann welche Strategie sinnvoll ist
Eine pauschale Empfehlung gibt es nicht. Stattdessen sollte die Entscheidung von Anforderungen an Sicherheit, Compliance, Performance und Betrieb abhängen.
- Split Tunnel passt, wenn Cloud- und Internetperformance kritisch ist, Bandbreite zentral begrenzt ist und Endpoint-Security stark ist.
- Full Tunnel passt, wenn zentrale Inspection erforderlich ist, Compliance streng ist oder du möglichst wenige Variablen im Client-Routing willst.
- Hybrid ist möglich: Standard Full Tunnel, aber definierte Ausnahmen (z. B. Videokonferenz, Windows Update) lokal.
Praxis-Blueprint: Split Tunneling mit IPv4 kollisionsarm umsetzen
Ein umsetzbarer Blueprint kombiniert Adressplanung, Präfixlisten und DNS-Design:
- Unternehmensadressraum: strukturierter 10.x-Plan mit Regionen/Standorten (keine Heimnetz-Standards verwenden)
- VPN-Client-Pool: eigener Bereich (z. B. 10.250.0.0/16), getrennte Policies
- Tunnelpräfixe: wenige, aggregierte Blöcke (Region-/Standortsummaries), plus gezielte Ausnahmen
- DNS: interne Domains über Unternehmensresolver, optional Split DNS
- Security: Host-Firewall + EDR, restriktive Zugriffe vom VPN-Pool, Logging für kritische Ziele
Outbound-Links für vertiefende Informationen
- Private IPv4-Adressbereiche (RFC 1918)
- CIDR und Classless Routing (RFC 4632)
- DNS Konzepte (RFC 1034)
- DNS Spezifikation (RFC 1035)
- IPsec Architektur (RFC 4301)
- Guide to IPsec VPNs (NIST SP 800-77r1)
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.
