# Windows VPN Client: Setup, Automatisierung & Best Practices

TL;DR / Management Summary In einer mobilen Arbeitswelt ist der VPN-Client die kritischste Applikation. Wir nutzen primär den integrierten Windows VPN-Client, da er keine Drittanbieter-Treiber benötigt und sich nahtlos in das Security-Center einfügt. Wir setzen auf IKEv2 für Stabilität oder SSTP als HTTPS-Fallback. Ein Senior Admin rollt VPN-Profile ausschließlich automatisiert via PowerShell oder Intune aus, um manuelle Fehlkonfigurationen zu vermeiden.

# 1. Einführung & Protokoll-Architektur

Wie die Datenpakete ‘schwimmen’.

Der Windows VPN-Stack unterstützt nativ mehrere Protokolle. Jedes hat seine Daseinsberechtigung:

# Vergleich der Protokolle

  1. IKEv2 (Internet Key Exchange v2): Der modernste Standard. Bietet hohe Performance und unterstützt MOBIKE (Wechsel zwischen WLAN und Mobilfunk ohne Verbindungsabbruch).
  2. SSTP (Secure Socket Tunneling Protocol): Nutzt TCP Port 443. Ideal für Umgebungen, in denen UDP blockiert wird (Hotels, Flughäfen).
  3. L2TP/IPsec: Veraltet, aber oft für die Anbindung alter Hardware-Firewalls nötig.
  4. PPTP: Unsicher! Nur noch für Testzwecke in isolierten Netzen verwenden.

# 2. Automatisierter Rollout (PowerShell)

Weg von ‘Neue Verbindung hinzufügen’.

Manuelle VPN-Konfiguration skaliert nicht. Wir nutzen das VpnClient Modul.

# Beispiel: IKEv2 Profil mit Split-Tunneling

Add-VpnConnection -Name "Corp-VPN" `
    -ServerAddress "vpn.firma.de" `
    -TunnelType "Ikev2" `
    -AuthenticationMethod "MachineCertificate" `
    -EncryptionLevel "Required" `
    -SplitTunneling $true `
    -AllUserConnection

# 3. Deep Dive: DNS & Routing im VPN

Die häufigste Fehlerquelle.

Oft steht der VPN-Tunnel, aber der User kann Server nicht per Namen erreichen.

# Name Resolution Policy Table (NRPT)

Für IKEv2/SSTP nutzt Windows die NRPT, um DNS-Anfragen für firmeninterne Suffixe gezielt an den VPN-DNS zu leiten.

Add-VpnConnectionRoute -ConnectionName "Corp-VPN" -DestinationPrefix "10.0.0.0/8"

# 4. Day-2 Operations: Authentifizierung & Security

Schutz vor Brute-Force.

# Zertifikatsbasierte Authentifizierung (EAP-TLS)

Anstatt Passwörter zu nutzen, authentifiziert sich der PC mit einem Zertifikat aus der eigenen PKI (Artikel 520).

# Always-On VPN

Windows kann den VPN-Tunnel automatisch aufbauen, sobald eine Internetverbindung besteht – noch vor dem User-Login.

# 5. Troubleshooting & “War Stories”

Wenn der Tunnel reißt.

# Top 3 Fehlerbilder

  1. Symptom: Fehler 809 (Server nicht erreichbar).

    • Ursache: UDP Port 500/4500 (IKEv2) ist durch den Heimrouter oder ISP blockiert.
    • Lösung: Fallback auf SSTP oder Prüfung des Routers auf “IPsec Passthrough”.

  2. Symptom: VPN verbindet, aber RDP auf interne Server schlägt fehl.

    • Ursache: Asymmetrisches Routing oder MTU-Probleme.
    • Lösung: MTU am VPN-Interface manuell auf 1350 setzen (netsh interface ipv4 set subinterface ...).

  3. Symptom: DNS-Auflösung geht nur via FQDN (server.firma.local), nicht via Hostname (server).

    • Lösung: DNS-Suffixe in der VPN-Konfiguration via GPO/Intune mitgeben.

# “War Story”: Der “Hidden” Proxy

Wir hatten einen Fall, bei dem hunderte User plötzlich keine VPN-Verbindung mehr aufbauen konnten. Die Entdeckung: Ein Windows-Update hatte die Proxy-Einstellungen (Artikel 436) für den System-Kontext (SYSTEM User) verändert. SSTP versuchte, den Firmen-Proxy zu nutzen, um die VPN-Adresse zu erreichen – was in einem Loop endete. Lehre: Überwachen Sie immer den WinHTTP Proxy-Status, da dieser auch den VPN-Stack beeinflusst.

# 6. Monitoring & Alerting

Transparenz im Gateway.

Überwachen Sie an Ihrem VPN-Gateway (z.B. OPNsense, Artikel 570):

# 7. Fazit & Empfehlung

Ein gut konfigurierter VPN-Client ist für den User unsichtbar.

# Anhang: Cheatsheet

Aufgabe Befehl
VPN Status prüfen Get-VpnConnection
Verbindung manuell starten rasdial "Firma-VPN"
VPN Log auf Desktop Get-WindowsUpdateLog (enthält oft auch Networking-Infos)
Alle Routen sehen route print

# Referenzen