„VPN verbindet, aber Internet geht nicht“ ist ein typisches Fehlerbild, das auf den ersten Blick paradox wirkt – und fast immer mit Split Tunnel zu tun hat. Denn Split Tunneling bedeutet: Nur bestimmte Netze (meist interne Subnetze) laufen durch den VPN-Tunnel, der restliche Traffic – insbesondere Internet und SaaS – soll lokal über den normalen Internetzugang gehen. Wenn danach plötzlich kein Internet mehr funktioniert, ist der Split-Tunnel-Mechanismus entweder nicht wirklich aktiv, oder er ist durch Routing-, DNS- oder Policy-Effekte „kaputtkonfiguriert“. Häufig steckt dahinter keine „VPN-Störung“, sondern eine Kombination aus falsch gepushten Routen (Default Route versehentlich im Tunnel), DNS-Resolvern, die nur intern erreichbar sind, einer fehlenden NAT-/Egress-Policy am Gateway, MTU/MSS-Problemen oder sogar einer Proxy-/PAC-Policy, die im VPN-Kontext anders greift. Das Gute: Diese Fälle lassen sich sehr systematisch diagnostizieren, weil Internetzugang ein klar definierter Datenpfad ist. Dieser Leitfaden zeigt Ihnen praxisnah, wie Sie Split Tunnel Diagnose betreiben: welche Checks auf Client und Gateway wirklich relevant sind, wie Sie die häufigsten Fehler in Minuten eingrenzen und welche Fixes nachhaltig funktionieren – ohne Sicherheitsrisiken durch „einfach alles full-tunneln“ oder pauschale Ausnahmen.

Split Tunnel kurz erklärt: Was soll eigentlich passieren?

Beim Split Tunnel gibt es zwei logische Pfade:

• Intern (Corporate): definierte interne Netze, z. B. 10.10.0.0/16, werden über den VPN-Tunnel geroutet.
• Extern (Internet/SaaS): alles andere bleibt lokal und nutzt die normale Default Route des Clients.

Damit das sauber funktioniert, müssen Routing und DNS zusammenpassen. Wenn Sie z. B. interne DNS-Server pushen, muss der Client diese auch erreichen können (über VPN). Gleichzeitig darf externer DNS nicht „kaputt“ gehen, sonst wirkt Internet „tot“, obwohl Routing ok wäre. DNS-Grundlagen sind in RFC 1034 und RFC 1035 beschrieben.

Erster Schritt: Ist es wirklich ein Internetproblem oder ein DNS-Problem?

Viele melden „Internet geht nicht“, meinen aber: „Webseiten öffnen nicht“. Das ist häufig DNS. Trennen Sie deshalb sofort IP-Erreichbarkeit von Namensauflösung.

Quick Tests auf dem Client

• IP-Test: Erreicht der Client eine öffentliche IP?
• DNS-Test: Kann der Client öffentliche Namen auflösen?

# Windows
ping 1.1.1.1
nslookup www.example.com
macOS/Linux
ping -c 3 1.1.1.1

dig www.example.com

Interpretation:

• IP geht, DNS geht nicht: Resolver/DoH/Policy-Problem, nicht Routing.
• IP geht nicht: Routing/Default Route/Proxy oder lokale Netzstörung.
• Beides geht nicht: häufig Default Route in den Tunnel gezogen, Gateway blockt oder Proxy/PAC greift falsch.

Typische Ursache 1: Default Route wurde versehentlich über VPN gesetzt

Der häufigste Split-Tunnel-Fehler ist ein unbeabsichtigtes „Quasi-Full-Tunnel“: Der Client bekommt eine Default Route (0.0.0.0/0) oder eine sehr breite Route (z. B. 0.0.0.0/1 und 128.0.0.0/1) über den VPN-Tunnel. Dann läuft Internettraffic durch den VPN-Pfad – aber das Gateway ist dafür nicht konfiguriert (kein NAT/Egress, Policy blockt), und Internet „stirbt“.

So prüfen Sie das

# Windows
route print
macOS
netstat -rn
Linux
ip route

Suchen Sie nach:

• Default Route über das VPN-Interface
• „def1“-ähnlichen Einträgen (z. B. 0.0.0.0/1 und 128.0.0.0/1)
• unerwartet breiten Routen (z. B. 10.0.0.0/8), die lokale Netze „schlucken“

Fix:

• Im VPN-Profil Split Tunneling korrekt aktivieren und sicherstellen, dass keine Redirect-Gateway/Default-Route-Pushes aktiv sind.
• Wenn Sie Full Tunnel nicht wollen: „redirect-gateway“ (OpenVPN) oder Default Route Policies (IKEv2/SSL-VPN) entfernen.
• Nur die wirklich benötigten internen Prefixes routen.

Typische Ursache 2: DNS-Server wurden auf interne Resolver gesetzt, die nicht erreichbar sind

Ein sehr häufiger Fehler: Das VPN pusht interne DNS-Server (z. B. 10.10.10.10). Bei Split Tunnel ist das grundsätzlich okay – aber nur, wenn der Client diese DNS-Server über den Tunnel erreichen kann und die Firewall DNS erlaubt. Wenn nicht, wird jede Namensauflösung langsam oder unmöglich. Das wirkt wie „Internet tot“.

So prüfen Sie DNS-Resolver

• Windows: ipconfig /all und Get-DnsClientServerAddress
• macOS: scutil --dns
• Linux: resolvectl status

Fix:

• Split-DNS nutzen: interne Domains über interne Resolver, externe Domains über lokale Resolver.
• Wenn Split-DNS nicht möglich ist: interner Resolver muss Rekursion ins Internet sauber können und erreichbar sein.
• Firewall-Regeln: DNS (UDP/TCP 53) vom VPN-Clientnetz zum internen Resolver erlauben.

Typische Ursache 3: Proxy/PAC/WPAD oder Secure Web Gateway greift falsch

In Unternehmen sind Proxy-Konfigurationen verbreitet: PAC-Dateien, WPAD oder feste Proxies. Wenn das VPN aktiv ist, können sich Regeln ändern (z. B. anderes DNS-Suffix, andere Erkennung), und der Client versucht plötzlich, den Proxy über einen Pfad zu erreichen, der nicht funktioniert.

• Symptom: Ping/IP geht, aber Browser lädt nichts; andere Apps funktionieren ggf. teilweise.
• Fix: Proxy-Einstellungen prüfen, PAC-URL erreichbar machen (über VPN oder lokal), Ausnahmen für VPN-Clients definieren.

Typische Ursache 4: Firewall/Policy am Gateway blockt Internet-Egress

Wenn Internettraffic doch über den Tunnel läuft (absichtlich oder versehentlich), muss das Gateway ihn ins Internet weiterleiten dürfen. Dazu braucht es:

• Firewall-Policy VPN-Zone → WAN/Internet erlaubt
• NAT/Masquerading (wenn Clients mit privaten IPs ins Internet gehen)
• DNS-Policy (wenn DNS über Gateway laufen soll)

Wenn diese Bausteine fehlen, ist Internet „tot“, sobald der Client den Default Route in den Tunnel bekommt.

Typische Ursache 5: MTU/MSS-Probleme – Internet geht „manchmal“ oder nur teilweise

Manchmal „geht Internet“, aber bestimmte Seiten oder große Downloads brechen ab. Dann ist häufig MTU/Fragmentierung schuld. VPN erzeugt Overhead, und in bestimmten Zugangsnetzen (PPPoE, Mobilfunk, zusätzliche Encapsulation) ist die effektive MTU kleiner. Path MTU Discovery ist in RFC 1191 (IPv4) und RFC 8201 (IPv6) beschrieben.

• Symptom: kleine Seiten gehen, große hängen; HTTPS lädt teilweise; Apps wirken instabil.
• Fix: MSS-Clamping am Gateway, Tunnel-MTU konservativ setzen, ICMP für PMTUD nicht blockieren.

Typische Ursache 6: IPv6-Leaks oder IPv6-Route-Verwirrung

Viele Split-Tunnel-Setups denken nur in IPv4. Wenn der Client IPv6 aktiv nutzt, kann es passieren, dass:

• IPv6-Traffic weiterhin lokal rausgeht, während IPv4 über VPN läuft (oder umgekehrt).
• DNS AAAA-Records liefert, aber IPv6-Pfad ist nicht funktionsfähig (Blackhole).

Ergebnis: Webseiten laden „komisch“ oder gar nicht. Fix: IPv6-Strategie definieren (IPv6 korrekt tunneln oder bewusst kontrolliert deaktivieren/steuern), DNS-Policy entsprechend setzen.

Systematischer Diagnoseablauf: Split Tunnel in 15 Minuten prüfen

Mit dieser Reihenfolge vermeiden Sie Trial-and-Error:

• 1) IP vs. DNS trennen: Ping auf IP und DNS-Auflösung testen.
• 2) Routing-Tabelle prüfen: Gibt es eine Default Route im VPN? Gibt es unerwartet breite Prefixes?
• 3) DNS-Resolver prüfen: Wurde auf interne DNS umgestellt? Sind diese erreichbar?
• 4) Proxy prüfen: PAC/WPAD/fester Proxy – ändert sich Verhalten im VPN?
• 5) Gateway prüfen: Wenn Internet über VPN läuft – NAT/Egress-Policy vorhanden?
• 6) MTU/MSS: Teilprobleme bei großen Transfers?
• 7) IPv6: AAAA-Records, IPv6-Routen, mögliche Leaks/Blackholes.

Konkrete Checks je Betriebssystem

Windows

• Routing: route print
• DNS: ipconfig /all, Get-DnsClientServerAddress
• Proxy: Einstellungen → Netzwerk & Internet → Proxy
• Test: ping 1.1.1.1, nslookup www.example.com

macOS

• Routing: netstat -rn
• DNS: scutil --dns
• Proxy: Systemeinstellungen → Netzwerk → Proxies
• Test: ping -c 3 1.1.1.1, dig www.example.com

Linux

• Routing: ip route
• DNS: resolvectl status oder cat /etc/resolv.conf
• Proxy: Umgebungsvariablen (HTTP_PROXY/HTTPS_PROXY), Desktop-Proxy-Settings
• Test: ping -c 3 1.1.1.1, dig www.example.com

Typische Fixes – ohne die Sicherheit zu verschlechtern

Wenn Sie den Fehler gefunden haben, sind diese Maßnahmen in der Praxis die saubersten:

• Routen präzisieren: Nur benötigte interne Netze pushen, keine breiten 10.0.0.0/8-„Bequemlichkeitsrouten“.
• Split-DNS einführen: interne Zonen intern, extern extern; oder interner Resolver mit stabiler Rekursion.
• Proxy-Regeln anpassen: PAC-Datei erreichbar machen und Ausnahmen definieren, damit VPN nicht „Proxy-only“ wird.
• Gateway-Egress sauber konfigurieren (falls Internet bewusst über VPN soll): NAT, Policies, Logging.
• MTU/MSS standardisieren: MSS-Clamping am Gateway, PMTUD zulassen.
• IPv6 sauber behandeln: entweder korrekt tunneln oder bewusst kontrollieren.

Best Practices: Split Tunnel so bauen, dass es stabil bleibt

• Dokumentation: Welche Prefixes werden gepusht? Welche DNS-Resolver? Welche Proxy-Regeln?
• Testmatrix: Büro-WLAN, Home-WLAN, Mobilfunk, Hotel-WLAN – Split Tunnel muss in allen funktionieren.
• Monitoring: DNS-Fail-Raten, Reconnects, MTU-Symptome (Drops/Retx), User-Tickets nach Netzen clustern.
• Rollback: Änderungen an Routen/DNS/Proxy immer versionieren und schnell zurückdrehen können.

Outbound-Links zur Vertiefung

• RFC 1034: DNS Concepts
• RFC 1035: DNS Specification
• RFC 1191: Path MTU Discovery (IPv4)
• RFC 8201: Path MTU Discovery (IPv6)
• BSI IT-Grundschutz: NET.3.3 VPN

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.