Wer mit Windows-VPN, Intune und Azure arbeitet, kennt das Muster: Das VPN-Profil ist als Split Tunnel konfiguriert, die gewünschten Zielnetze sind sauber eingetragen, und trotzdem verschwinden nach dem Verbindungsaufbau plötzlich lokale Netze. Genau das macht die Fehlersuche tückisch: Auf den ersten Blick sehen Azure, Intune und das VPN-Profil korrekt aus. Die eigentliche Ursache kann jedoch tiefer im Windows-VPN-Stack liegen. Microsoft dokumentiert dafür die Einstellung DisableClassBasedDefaultRoute im VPNv2 CSP.
Das Fehlerbild in der Praxis
Ein typisches Beispiel:
Ein Gerät baut per IKEv2 eine Verbindung zu Azure auf. Im Profil ist Split Tunnel aktiv, und als Zielroute ist nur ein bestimmtes Netz eingetragen, etwa 10.51.0.0/16. Gleichzeitig existieren lokal weitere Netze, zum Beispiel 10.53.2.0/24 oder 10.53.3.0/24. Nach dem VPN-Aufbau ist dann plötzlich ein lokales VLAN nicht mehr erreichbar, obwohl es nie als VPN-Ziel konfiguriert wurde. Genau solche Fälle entstehen, wenn die effektive Routentabelle nicht mit der sichtbaren Konfiguration übereinstimmt. Windows ergänzt in bestimmten Fällen zusätzliche class-based Routen automatisch.
Warum Split Tunnel allein nicht ausreicht
Viele gehen stillschweigend davon aus, dass Split Tunnel automatisch bedeutet: „Nur die eingetragenen Netze gehen durch den Tunnel.“ Das ist als Arbeitshypothese zu einfach. Microsoft unterscheidet klar zwischen den expliziten Split-Tunnel-Routen und weiteren Verhaltenseinstellungen des VPN-Profils. Eine davon ist DisableClassBasedDefaultRoute. Wenn diese Option nicht gesetzt ist und das VPN-Interface eine Adresse aus einem klassischen Netzbereich erhält, kann Windows zusätzlich eine class-based Route erzeugen. Bei einer 10.x-IP ist das typischerweise 10.0.0.0/8.
Was DisableClassBasedDefaultRoute konkret bewirkt
Im VPNv2-CSP beschreibt Microsoft, dass DisableClassBasedDefaultRoute genau dieses Verhalten steuert. Ist die Option nicht deaktiviert, kann Windows anhand der Interface-IP eine class-based Route ergänzen. Hat das VPN-Interface also zum Beispiel eine Adresse wie 10.52.x.x, dann kann daraus automatisch die Route 10.0.0.0/8 entstehen. Das ist technisch erklärbar, operativ aber gefährlich: Alle lokalen 10er-Netze, für die es keine spezifischere lokale Route gibt, werden dann plötzlich über das VPN-Interface geschickt.
Warum das in produktiven Umgebungen problematisch ist
In vielen Kundenumgebungen liegen lokale VLANs ebenfalls im 10er-Bereich. Wenn Windows dann zusätzlich 10.0.0.0/8 auf das VPN-Interface legt, reicht schon ein lokales Netz wie 10.53.2.0/24, um in Schwierigkeiten zu geraten. Das direkt angeschlossene Netz des Clients bleibt oft noch erreichbar, weil dafür eine spezifischere Route existiert. Andere interne Netze verschwinden jedoch scheinbar „zufällig“. Genau dadurch wirkt das Problem erst wie ein Fehler in Azure, Intune, der Firewall oder im VLAN-Routing, obwohl die Ursache tatsächlich im Verhalten des Windows-VPN-Profils liegt.
Woran man den Fehler erkennt
Der entscheidende Blick geht nicht zuerst ins Azure-Portal, sondern auf den Client. Wer nur die Intune-Oberfläche oder die Azure Point-to-Site-Konfiguration prüft, übersieht leicht die tatsächlich wirksamen Routen. Belastbar wird die Analyse erst mit:
route printGet-NetRouteGet-VpnConnection -AllUserConnection- und bei klassischen Windows-VPN-Profilen zusätzlich der
rasphone.pbk-Datei
Gerade die rasphone.pbk zeigt oft deutlicher als die UI, ob DisableClassBasedDefaultRoute aktiv oder inaktiv ist. Microsoft beschreibt zudem, dass viele erweiterte VPN-Optionen nicht vollständig in jeder MDM-Oberfläche erscheinen und daher über ProfileXML bzw. den VPNv2 CSP gesetzt werden.
Die GUI-Entsprechung in Windows
Wer sich die Adaptereigenschaften eines Windows-VPN-Profils ansieht, findet unter den erweiterten IPv4-Einstellungen den Haken „Klassenbasiertes Hinzufügen der Route deaktivieren“. Das ist fachlich genau die GUI-Entsprechung zu DisableClassBasedDefaultRoute. Wird dieser Haken gesetzt, wird die automatische class-based Route unterdrückt. Bleibt er aus, kann Windows bei einer 10.x-IP eben doch 10.0.0.0/8 hinzufügen — selbst wenn das Profil formal als Split Tunnel konfiguriert ist.
Warum Intune hier schnell an Grenzen kommt
Das normale Windows-VPN-Profil in Intune deckt viele Standardfälle ab: Split Tunnel, Always On, DNS, Routen, Zertifikate. Schwieriger wird es bei den erweiterten Eigenschaften. Microsoft weist explizit darauf hin, dass ProfileXML im VPNv2-CSP für Features gedacht ist, die von MDM-Oberflächen nicht vollständig unterstützt werden. Trusted Network Detection ist dafür ein weiteres gutes Beispiel: Diese Auto-Trigger-Logik arbeitet über DNS-Suffixe und ist eher ein ProfileXML-/CSP-Thema als eine simple Standardoption.
Die saubere Lösung
Die Lösung besteht nicht darin, zusätzliche Verkehrsregeln für die VPN-Verbindung anzulegen. Solche Filter regeln nicht die zugrunde liegende class-based Route. Die saubere Behebung ist, DisableClassBasedDefaultRoute explizit auf true zu setzen. Genau dafür ist der CSP-Knoten unter VPNv2/{ProfileName}/NativeProfile/DisableClassBasedDefaultRoute vorgesehen. Wird diese Option aktiv gesetzt, bleibt das Split-Tunnel-Verhalten auf die tatsächlich gewünschten Netze begrenzt.
Beispiel aus der Praxis
Ein funktionierendes Zielbild sieht so aus:
- IKEv2
- Maschinenzertifikat zur Authentifizierung
- Always On
- Split Tunnel
- Trusted Network Detection über interne DNS-Suffixe
- explizite Route, z. B.
10.51.0.0/16 DisableClassBasedDefaultRoute=true
Damit verbindet sich das Gerät automatisch, wenn es nicht im vertrauenswürdigen internen Netz ist, und routet trotzdem nicht pauschal alle 10er-Netze durch den Tunnel. Microsoft beschreibt sowohl Always On als auch Trusted Network Detection und ProfileXML als offizielle Bausteine dieses Ansatzes.
Was man daraus für den Betrieb lernen sollte
Die relevante Erkenntnis ist nicht: „Windows macht komische Dinge.“
Die relevantere Erkenntnis ist: Bei Windows-VPN darf man sich nicht nur auf die sichtbare Split-Tunnel-Konfiguration verlassen. Wer produktive VPN-Profile mit 10er-Netzen baut, sollte standardmäßig prüfen:
- Welche Routen landen effektiv auf dem Client?
- Ist
DisableClassBasedDefaultRoutegesetzt? - Gibt es lokale Netze, die versehentlich vom Tunnel eingefangen werden?
- Ist Trusted Network Detection sauber definiert?
Gerade in Intune-/Azure-Umgebungen spart diese Prüfung Zeit, weil sie eine ganze Reihe falscher Verdachtsmomente ausschließt.
Fazit
Wenn ein Windows-VPN-Interface eine 10.x-Adresse bekommt und DisableClassBasedDefaultRoute nicht aktiv gesetzt ist, kann Windows automatisch 10.0.0.0/8 routen. In Umgebungen mit lokalen 10er-Netzen führt das schnell zu schwer erkennbaren Routing-Konflikten. Die Lösung ist unspektakulär, aber entscheidend: Split Tunnel plus DisableClassBasedDefaultRoute=true. Wer das in seinen Standard für Windows-VPN-Profile aufnimmt, vermeidet einen Fehler, der in der Praxis deutlich häufiger ist, als man zunächst denkt.
Geschrieben von:
