VPN Routing richtig konfigurieren: Default Route vs. Selektives Routing

VPN Routing richtig konfigurieren ist die Grundlage dafür, dass ein VPN nicht nur „verbunden“ ist, sondern auch zuverlässig und sicher funktioniert. In der Praxis entstehen die meisten VPN-Probleme nicht durch Verschlüsselung oder das Protokoll, sondern durch Routing-Entscheidungen: Soll der gesamte Traffic über den Tunnel laufen (Default Route / Full Tunnel) oder nur bestimmte Ziele (selektives Routing / Split Tunnel)? Eine falsche Wahl führt schnell zu Symptomen wie „VPN ist langsam“, „SaaS funktioniert schlecht“, „Intranet geht, aber Drucker nicht“, „DNS leakt“, „Teams/Zoom ruckeln“ oder „nichts geht, sobald VPN an ist“. Gleichzeitig ist Routing auch ein Security-Thema: Default Route ermöglicht zentrale Kontrolle (Webfilter, Logging, DLP), während selektives Routing Performance verbessert, aber zusätzliche Schutzmaßnahmen erfordert. Dieser Artikel erklärt verständlich, wie Default Route und selektives Routing technisch funktionieren, wann welche Variante sinnvoll ist, wie Sie beide sauber konfigurieren und welche typischen Stolperfallen (DNS, IPv6, Asymmetrie, MTU) Sie vermeiden sollten.

VPN-Routing verstehen: Was passiert beim Verbindungsaufbau?

Ein VPN-Tunnel ist ein virtuelles Interface (z. B. tun/tap, IKEv2-Adapter, SSL-VPN-Interface). Sobald der Client verbunden ist, erhält er typischerweise:

• eine VPN-IP (Client-Adresse im Tunnel)
• DNS-Einstellungen (Resolver, Suchdomänen, ggf. Split-DNS)
• Routen (welche Zielnetze über den Tunnel gehen)

Das Routing entscheidet anschließend, ob ein Paket zum Ziel über das lokale Interface (WLAN/LAN) oder über das VPN-Interface gesendet wird. Technisch ist das unabhängig vom VPN-Protokoll (IPsec/IKEv2, TLS-VPN, WireGuard). Grundlagen zu IPsec sind in RFC 4301 beschrieben und IKEv2 in RFC 7296; TLS 1.3 als Basis für TLS-VPNs ist in RFC 8446 dokumentiert.

Default Route im VPN: Full Tunnel einfach erklärt

Bei der Default Route wird die Standardroute (0.0.0.0/0 und ggf. ::/0) so gesetzt, dass aller Traffic über das VPN-Interface geht. Der Client „sieht“ das VPN-Gateway dann als Weg ins Internet und ins interne Netz. Das ist Full Tunnel.

• IPv4 Default Route: 0.0.0.0/0 zeigt auf das VPN-Interface
• IPv6 Default Route: ::/0 zeigt auf das VPN-Interface (falls IPv6 getunnelt wird)

Der Vorteil: Kontrolle und Konsistenz. Der Nachteil: Backhaul (Umwege) und höhere Last auf Gateways.

Selektives Routing im VPN: Split Tunnel verständlich erklärt

Bei selektivem Routing (Split Tunnel) bekommt der Client nur Routen zu definierten Zielnetzen oder Hosts, z. B. 10.0.0.0/8, 172.16.0.0/12 oder einzelne Subnetze für Intranet und Server. Internettraffic bleibt lokal und läuft nicht durch das VPN.

• Nur interne Netze werden über das VPN geroutet
• Internet/SaaS bleibt lokal (bessere Performance, weniger Gateway-Last)
• DNS muss sauber geplant werden (Split-DNS), sonst scheitern interne Namen oder leaken nach außen

Wann ist Default Route sinnvoll – und wann nicht?

Default Route ist vor allem dann sinnvoll, wenn zentrale Security- und Compliance-Anforderungen im Vordergrund stehen oder wenn Clients in unsicheren Netzen arbeiten.

• Sensible Daten & Compliance: zentrale Webfilter/DLP/Logging, konsistente Policies
• Untrusted Networks: Hotel-WLAN, öffentliche Netze, Gastnetze
• Privileged Access: Admin-Zugriffe, Management-Zonen, streng kontrollierte Pfade
• Einheitliche DNS-Policy: interne und externe Auflösung über definierte Resolver

Default Route ist oft weniger geeignet, wenn Nutzer primär SaaS verwenden, international verteilt sind oder wenn Videokonferenzen und Cloud-Workloads stark leiden.

Wann ist selektives Routing sinnvoll – und wann nicht?

Selektives Routing ist häufig die bessere Wahl, wenn Performance und Nutzererlebnis kritisch sind und wenn Sie eine moderne SaaS- und Cloud-Strategie haben.

• SaaS-first: Teams, M365, Google Workspace, GitHub – direkte Pfade sind oft besser
• Internationale Teams: weniger Backhaul, geringere RTT
• Skalierung: reduziert Gateway- und Egress-Last
• Filialen: lokaler Internet-Breakout möglich, nur interne Ziele über Tunnel

Selektives Routing ist riskanter, wenn Endpoint-Security schwach ist, DNS/IPv6 nicht sauber gehandhabt wird oder wenn Ihr Sicherheitsmodell zentrale Inspektion erfordert.

Security-Auswirkungen: Default Route vs. selektives Routing

Routing ist auch ein Sicherheits- und Governance-Thema. Entscheidend ist, wo Sie Kontrollen platzieren:

• Default Route: Kontrolle zentral am VPN-Gateway (Webproxy, IDS/IPS, DLP, Logging)
• Selektives Routing: Kontrolle stärker am Endpoint und über Cloud-Security (EDR, Secure Web Gateway, CASB)

Ein praxistauglicher Ansatz ist risikobasiert: Full Tunnel für Admins und Hochrisiko-Szenarien, Split Tunnel für Standardnutzer auf verwalteten Geräten mit starker Endpoint-Security.

DNS und Routing gehören zusammen: Ohne Split-DNS wird Split Tunnel fragil

Mit Split Tunnel müssen interne Namen über interne Resolver aufgelöst werden, während externe Namen effizient extern aufgelöst werden dürfen. Sonst passieren zwei Dinge:

• Interne Auflösung scheitert: intranet.corp.local wird über ISP-DNS gefragt und kommt nicht zurück.
• DNS-Leaks: interne Hostnames/Suchdomänen gehen nach außen.

DNS-Grundlagen sind in RFC 1034 und RFC 1035 beschrieben. Für VPN-nahe Sicherheitsanforderungen ist der BSI-Baustein NET.3.3 hilfreich (BSI IT-Grundschutz: NET.3.3 VPN).

IPv6: Der häufigste „Routing-Leak“, den Teams übersehen

Viele VPN-Setups konfigurieren nur IPv4-Routen. Wenn Clients jedoch IPv6 aktiv haben, kann Traffic am VPN vorbei laufen – selbst bei vermeintlichem Full Tunnel. Das führt zu:

• Security-Leaks: Traffic geht lokal ins Internet statt durch den Tunnel
• DNS-Problemen: AAAA-Records werden genutzt, aber IPv6 wird nicht getunnelt
• „Geht manchmal“: Anwendungen wählen je nach Netzwerk IPv4 oder IPv6

Best Practice: IPv6 bewusst planen – entweder konsequent tunneln (Default ::/0) oder kontrolliert so handhaben, dass keine Leaks entstehen.

Asymmetrisches Routing: Wenn Hin- und Rückweg nicht zusammenpassen

Ein typischer Fehler bei selektivem Routing und hybriden Netzen: Pakete gehen über den VPN-Tunnel hin, kommen aber über einen anderen Pfad zurück. Stateful Firewalls oder NAT-Gateways verwerfen dann Rückpakete. Symptome:

• Verbindungen bauen sich auf und brechen ab
• Bestimmte Anwendungen funktionieren nur sporadisch
• ICMP/Ping wirkt ok, TCP-Sessions sind instabil

Lösung: Rückwege sauber planen (Routen im Rechenzentrum/Cloud, NAT-Design, ggf. BGP bei komplexen Setups).

MTU/MSS: Routing-Entscheidungen beeinflussen Paketgrößen-Probleme

Routing beeinflusst, welche Pfade ein Paket nimmt – und damit auch die kleinste MTU im Pfad. Bei Full Tunnel kann zusätzlicher Backhaul über Provider oder Cloud-Edges zu MTU-Problemen führen. Bei Split Tunnel können unterschiedliche Pfade (lokal vs. Tunnel) unterschiedliche MTU-Eigenschaften haben.

• Symptom: Große Transfers hängen, bestimmte Websites laden nicht
• Maßnahmen: MSS-Clamping, PMTUD ermöglichen, Tunnel-MTU definieren

PMTUD ist in RFC 1191 (IPv4) und RFC 8201 (IPv6) beschrieben.

Konfigurationsmuster für Unternehmen: Drei praxiserprobte Routing-Modelle

Statt „entweder oder“ nutzen viele Organisationen heute mehrere Profile – je Rolle und Risiko.

Modell A: Full Tunnel für alle (klassisch, kontrolliert)

• Default Route über VPN (0.0.0.0/0 und ggf. ::/0)
• DNS vollständig über Unternehmensresolver
• Zentraler Egress mit Webfilter/Logging
• Erfordert starke Gateway-Kapazität und oft regionale Gateways für Performance

Modell B: Split Tunnel als Standard, Full Tunnel für Hochrisiko

• Standardnutzer: selektive Routen zu internen Netzen
• Admins/High-Risk: Full Tunnel + zusätzliche MFA + Bastion
• Split-DNS für interne Zonen, externe Resolver lokal oder über Secure Web Gateway

Modell C: App-zentrierter Zugriff statt Netzrouting

• Kein „Netzzugriff“, sondern Zugriff auf definierte Anwendungen (Portal/Proxy/ZTNA)
• Reduziert Routing-Komplexität, sehr granulare Policies
• Besonders geeignet für BYOD, Partner und Dienstleister

Troubleshooting: Wenn Routing im VPN nicht tut, was es soll

Wenn Nutzer melden „VPN verbunden, aber…“, hilft ein strukturierter Ablauf:

• Routing-Tabelle prüfen: existiert Default Route über VPN oder nur selektive Routen?
• Interface-Metrik: priorisiert das OS das richtige Interface?
• DNS prüfen: welcher Resolver ist aktiv, funktionieren interne Zonen?
• Traceroute/mtr: läuft Traffic tatsächlich durch den Tunnel oder lokal?
• IPv6 testen: geht IPv6 am Tunnel vorbei, AAAA wird bevorzugt?
• Firewall/Policies: ist das Ziel im VPN erlaubt, oder blockt eine Policy?

Best Practices: Default Route und selektives Routing sauber betreiben

• Risikobasiertes Profilmodell: nicht alle Nutzer brauchen denselben Tunnelmodus.
• Split-DNS konsequent: interne Zonen intern, DNS-Leaks vermeiden.
• IPv6 bewusst planen: tunneln oder kontrollieren, aber nicht ignorieren.
• Routing dokumentieren: welche Netze sind über VPN erreichbar, warum, wer ist Owner?
• Monitoring: Abbruchraten, Login-Zeit, RTT/Loss, DNS-Fehler, Gateway-CPU.
• Asymmetrie vermeiden: Rückwege im Rechenzentrum/Cloud sauber konfigurieren.
• MTU/MSS beachten: MSS-Clamping und PMTUD-Strategie einplanen.

Weiterführende Quellen (Outbound-Links)

• RFC 1034: DNS Grundlagen
• RFC 1035: DNS Spezifikation
• RFC 4301: IPsec Architecture
• RFC 7296: IKEv2
• RFC 8446: TLS 1.3
• 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.