Split Tunneling: Konzepte und Risiken im Unternehmensnetz

Split Tunneling ist ein Remote-Access-VPN-Konzept, bei dem nur „Unternehmensverkehr“ durch den VPN-Tunnel geleitet wird, während Internet-Traffic des Clients direkt über den lokalen Anschluss läuft. Das spart Bandbreite und entlastet zentrale Gateways, erhöht aber die Angriffsfläche: Der Client ist gleichzeitig im Unternehmensnetz und im offenen Internet. Für ein sicheres Unternehmensdesign musst du Split Tunneling deshalb bewusst steuern (Subnetz-/App-Scopes, DNS, Security-Controls) und die Risiken organisatorisch sowie technisch mitigieren.

Grundkonzept: Split Tunnel vs. Full Tunnel

Beim Full Tunnel geht der gesamte Traffic (inkl. Internet) über den VPN-Gateway. Beim Split Tunnel werden nur definierte Ziele (Subnets, Domains, Apps) über den Tunnel gesendet. Der Rest bleibt lokal.

• Full Tunnel: maximale Kontrolle, höhere Last und Latenz
• Split Tunnel: weniger Last, bessere Performance, höhere Risiken
• Entscheidung hängt von Security-Policy und Betriebsanforderungen ab

Routing-Prinzip als Logik

$\text{Wenn Ziel ∈ Corporate-Scopes} \to \text{VPN}, \text{sonst} \to \text{lokales Internet}$

Warum Unternehmen Split Tunneling einsetzen

Split Tunnel ist häufig eine Kapazitäts- und Performance-Entscheidung. Besonders bei vielen Remote-Usern kann Full-Tunnel das zentrale VPN-Gateway, die Internet-Uplinks und Security-Stacks (Proxy, IDS/IPS) stark belasten.

• Bandbreite sparen: Internet-Traffic bleibt lokal
• Latenz reduzieren: Cloud-/SaaS-Ziele oft schneller lokal erreichbar
• Gateway entlasten: weniger Sessions/Throughput zentral
• Stabilität erhöhen: weniger Abhängigkeit vom Unternehmens-Internetbreakout

Die Kernrisiken von Split Tunneling

Das Sicherheitsproblem ist die „Dual-Homing“-Situation: Der Client ist gleichzeitig im Unternehmensnetz (über VPN) und im offenen Internet. Damit steigt das Risiko, dass ein kompromittierter Client als Brücke (Pivot) ins Unternehmensnetz wirkt.

• Bridging/Pivoting: Malware nutzt den VPN-Tunnel als Seiteneinstieg
• DNS-Risiken: falsche Namensauflösung, Leaks, Split-DNS-Komplexität
• Shadow IT: Traffic umgeht zentrale Security-Controls (Proxy/IPS)
• Compliance: Logging/Inspection des Internet-Traffics fehlt zentral

Split Tunnel Scope sauber definieren

Die wichtigste technische Maßnahme ist eine präzise Scope-Definition: Welche Netze (CIDR), welche Dienste (Apps/Domains) und welche Routen müssen in den Tunnel? Je kleiner und klarer der Scope, desto geringer das Risiko.

• Subnetzbasiert: nur definierte RFC1918-/Corporate-Netze
• Service-basiert: nur bestimmte Apps/Domains (plattformabhängig)
• Hybrid: kritische Systeme Full-Tunnel, Rest Split

Beispiel: Split-Tunnel-ACL für Corporate-Netze

ip access-list standard SPLIT_TUNNEL
 permit 10.0.0.0 0.255.255.255
 permit 172.16.0.0 0.15.255.255
 permit 192.168.0.0 0.0.255.255

DNS-Design: der häufigste technische Stolperstein

Split Tunneling ist nur dann betriebssicher, wenn DNS konsistent ist. Typische Fehlerbilder sind: interne Namen funktionieren nicht, SaaS geht, aber Intranet nicht; oder DNS-Leaks über lokale Resolver. In vielen Designs wird internes DNS über den Tunnel erzwungen, während externes DNS lokal bleibt – oder umgekehrt, je nach Security-Policy.

• Split DNS: interne Domains → interne Resolver, externe Domains → externe Resolver
• DNS-Leak vermeiden: klare Resolver-Policy, ggf. „DNS over VPN“
• Besonders kritisch: identische Domains intern/extern (Split-Horizon)

Indiz im Betrieb: „Nur Namen gehen nicht“

Client$ nslookup intranet.corp.local
Client$ nslookup www.example.com

Security-Mitigations: Wie du Split Tunnel vertretbar machst

Split Tunnel kann sicher sein, wenn du Endpoint-Security und Netzwerk-Controls entsprechend anpasst. Ziel ist, dass der Client nicht zur „Bridge“ wird und dass Unternehmenszugriffe weiterhin kontrolliert und geloggt werden.

• MFA + Device Posture (nur compliant devices ins VPN)
• Endpoint Firewall/EDR verpflichtend (Inbound lokal restriktiv)
• Least Privilege im Netz: Segmentierung, minimaler Zugriff auf Server
• CoPP/ACLs am Gateway: nur benötigte Zugriffe zulassen
• Split Tunnel nur für definierte Gruppen/Use-Cases (Role-based Policy)

Routen und Overlaps: Home-Netze als Praxisproblem

Viele Home-Netze nutzen 192.168.0.0/24 oder 192.168.1.0/24. Wenn Unternehmensnetze ähnlich sind, kann Split Tunnel zu Overlaps führen: Traffic geht lokal statt in den Tunnel. Das erzeugt „komische“ Unerreichbarkeiten.

• Adress-Overlaps: lokale RFC1918-Netze kollidieren mit Corporate
• Symptom: einzelne Subnetze nicht erreichbar, obwohl VPN „connected“
• Lösungen: Adressdesign bereinigen oder spezielle Client-Routen/Policies

Full Tunnel als Alternative: Wann er trotz Last sinnvoll ist

Wenn du starke Compliance-Anforderungen hast oder Internet-Traffic zentral inspecten musst, ist Full Tunnel oft die klare Wahl. Auch bei hohem Risiko-Exposure (BYOD, untrusted Geräte) ist Full Tunnel plus striktes Policy-Set häufig sicherer.

• Compliance/Forensik: zentraler Proxy/IDS/IPS, zentrales Logging
• Hohes Risk: BYOD oder wenig kontrollierte Endgeräte
• Einheitliche Policy: „alles durch die Unternehmens-Security“

Verifikation: Woran erkennst du, ob Split Tunnel korrekt arbeitet?

Du prüfst Routen (welche Netze gehen über VPN), DNS-Auflösung und den tatsächlichen Pfad zu internen und externen Zielen. Traceroute zeigt zuverlässig, ob der Traffic über den Tunnel geht.

Routing prüfen

Client$ route print
Client$ netstat -rn

Pfad prüfen

Client$ traceroute 10.10.10.10
Client$ traceroute 8.8.8.8

Best Practices als Kurzcheckliste

• Split-Tunnel-Scopes minimal und dokumentiert halten
• DNS-Policy bewusst designen (Split DNS, Leak vermeiden)
• Endpoint-Security (EDR, Firewall) verpflichtend
• MFA + Device-Compliance vor VPN-Zugang
• Segmentierung im Unternehmensnetz, keine „flache“ VPN-Zone
• Regelmäßige Reviews: welche Netze/Apps sind im Split enthalten?

Konfiguration speichern

Router# copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.