Jeder Admin, der VPN-Verbindungen für Mitarbeitende im Homeoffice oder Außendienst konfiguriert, steht irgendwann vor derselben Frage: Soll der gesamte Datenverkehr durch den Tunnel laufen, oder nur der, der ins Firmennetz muss? Die Antwort ist nicht pauschal – sie hängt von der Infrastruktur, der Sicherheitsarchitektur und den konkreten Anforderungen ab.
Full Tunnel: Alles durch den Tunnel
Beim Full Tunnel wird der gesamte Netzwerkverkehr des Clients über die VPN-Verbindung geroutet – egal ob der Benutzer auf den internen Fileserver zugreift oder YouTube öffnet. Das Default Gateway des Clients zeigt auf den VPN-Adapter, nicht auf den lokalen Router.
Vorteil: Die IT behält die volle Kontrolle. DNS-Anfragen laufen über die internen Server, Web-Traffic kann über den Firmen-Proxy gefiltert werden, und Data Loss Prevention greift unabhängig davon, wo der Client physisch steht. Für Umgebungen mit strengen Compliance-Anforderungen – NIS2, BSI-Grundschutz, ISO 27001 – ist das oft die einzige vertretbare Konfiguration.
Nachteil: Der gesamte Internet-Traffic der Homeoffice-Benutzer läuft über die Firmenfirewall. Bei 50 Mitarbeitenden im Homeoffice, die parallel Teams-Calls führen, OneDrive synchronisieren und nebenbei Spotify laufen haben, wird die WAN-Leitung am Standort schnell zum Flaschenhals. Latenz steigt, Videokonferenzen ruckeln, Benutzer beschweren sich.
Split Tunneling: Nur Firmenverkehr im Tunnel
Split Tunneling teilt den Datenverkehr auf. Zugriffe auf interne Ressourcen – Fileserver, Intranet, RDP-Verbindungen zu Terminalservern – gehen durch den Tunnel. Alles andere nimmt den direkten Weg über den lokalen Internetanschluss des Benutzers.
Vorteil: Die Firmenfirewall wird entlastet, Latenz sinkt, Microsoft-365-Dienste performen deutlich besser. Microsoft empfiehlt für Teams, SharePoint Online und OneDrive ausdrücklich Split Tunneling, weil die Dienste über ein globales Edge-Netzwerk ausgeliefert werden und ein Umweg über den Firmenstandort die Performance verschlechtert. In der Praxis lässt sich das über die Routing-Tabelle des VPN-Clients oder – bei Windows Always On VPN – über die ProfileXML-Konfiguration sauber umsetzen.
Nachteil: Der Client ist mit einem Bein im Firmennetz und mit dem anderen im offenen Internet. DNS-Leaks, unkontrollierter Web-Zugriff und fehlender Proxy-Schutz sind reale Risiken. Wer Split Tunneling konfiguriert, muss sicherstellen, dass der Client trotzdem über Endpoint Protection, lokale Firewall-Regeln und erzwungene DNS-Konfiguration abgesichert ist. Ohne Conditional Access und Geräte-Compliance in Entra ID ist Split Tunneling in vielen Umgebungen schlicht zu riskant.
Was das BSI dazu sagt
Das BSI stellt in seinem Kompendium für Telekommunikationssysteme klar: „Da ein Split Tunneling aus Sicherheitsgründen zu vermeiden ist”, soll der gesamte Traffic über den Tunnel laufen. Split Tunneling wird nur dann als akzeptabel behandelt, wenn der Client über ausreichende lokale Schutzmechanismen verfügt und der Tunnel-Split dokumentiert und begründet ist. Für Umgebungen, die BSI-Grundschutz oder NIS2 umsetzen, bedeutet das: Split Tunneling geht – aber nicht ohne Nachweis, dass die Endpoint-Sicherheit den Wegfall des zentralen Proxy-Schutzes kompensiert.
VPN-Dienste als Ergänzung – nicht als Ersatz
In Umgebungen ohne eigene VPN-Infrastruktur – etwa bei Freelancern, Kleinstunternehmen oder Mitarbeitenden, die über private Geräte arbeiten – kann ein kommerzieller VPN-Dienst den Internet-Traffic verschlüsseln und DNS-Anfragen absichern. Das ersetzt keinen Site-to-Site-Tunnel und kein Always On VPN mit Zertifikatsauthentifizierung, schließt aber die Lücke, die entsteht, wenn Mitarbeitende über öffentliche WLANs oder ungesicherte Heimnetzwerke auf Cloud-Dienste zugreifen.
Fazit
Full Tunnel ist die sichere Wahl für regulierte Umgebungen. Split Tunneling ist die performante Wahl für Microsoft-365-lastigen Traffic. In der Praxis landet man oft bei einem Hybrid: Full Tunnel als Default, mit definierten Ausnahmen für Microsoft-Endpoints und gegebenenfalls Videokonferenz-Dienste.
Wer sich für Split Tunneling entscheidet, sollte mindestens folgende Punkte dokumentieren: welche Zielnetze durch den Tunnel laufen, welche Ausnahmen definiert sind und warum, wie der Endpoint ohne zentralen Proxy abgesichert wird und wer die Konfiguration bei Änderungen überprüft. Entscheidend ist nicht, welches Modell man wählt, sondern ob die Entscheidung dokumentiert, die Endpoint-Sicherheit angepasst und die Routing-Konfiguration regelmäßig überprüft wird. Der Tunnel ist nur so sicher wie das, was an beiden Enden steht.