Windows VPN Client einrichten: IKEv2 und Zertifikate

Ein Windows VPN Client einrichten mit IKEv2 und Zertifikaten ist in vielen Unternehmen der „Goldstandard“ für einen stabilen, sicheren Remote-Zugang: IKEv2 ist robust bei wechselnden Netzwerken (WLAN ↔ Mobilfunk), unterstützt moderne Kryptografie und lässt sich mit zertifikatsbasierter Authentifizierung sehr sauber in Unternehmensprozesse integrieren. Gleichzeitig scheitern Setups in der Praxis häufig nicht am Tunnel selbst, sondern an Zertifikatsdetails: falscher Zertifikatsspeicher (Benutzer vs. Computer), fehlende EKU (ClientAuth/ServerAuth), unvollständige Trust Chain, nicht erreichbare CRL/OCSP-Endpoints, falsche Subject/SAN-Namen oder ein Gateway-Zertifikat, das nicht zum Servernamen passt. Der Windows-Bordclient ist zudem im GUI bewusst vereinfacht – viele professionelle Einstellungen (IPsec-Parameter, Split Tunneling, DNS-Suffix, Always On) lassen sich zuverlässiger per PowerShell setzen. Dieser Artikel führt Sie Schritt für Schritt durch ein praxistaugliches Setup: Welche Zertifikate brauchen Sie, wie importieren Sie sie korrekt, wie erstellen Sie eine IKEv2-Verbindung in Windows 10/11, welche IPsec-Settings sind üblich, wie Sie Always On VPN als nächstes Level nutzen und welche Troubleshooting-Checks die häufigsten Fehler wie 809 oder 13801 schnell eingrenzen.

Warum IKEv2 auf Windows als Remote-Access-VPN oft die beste Wahl ist

IKEv2 ist das Schlüssel­aushandlungsprotokoll für IPsec und gilt als moderner Nachfolger von IKEv1. Es ist standardisiert, breit implementiert und in der Praxis stabiler als viele Legacy-Varianten. Technische Referenz ist RFC 7296 (IKEv2).

• Stabil bei Roaming: IKEv2 verkraftet Netzwerkwechsel typischerweise besser als ältere VPN-Stacks.
• Gute Interoperabilität: Viele Firewalls/VPN-Gateways unterstützen IKEv2 standardnah.
• Starke Sicherheit: In Kombination mit Zertifikaten und PFS (Perfect Forward Secrecy) sehr robust.
• Windows-Bordmittel: Kein zusätzlicher Client nötig, was Betrieb und Rollout vereinfacht.

Zertifikate verstehen: Welche brauchen Sie für IKEv2 unter Windows?

Für IKEv2 mit Zertifikaten gibt es im Kern zwei Authentifizierungsmodelle:

• Maschinenzertifikat (Computer): der PC authentifiziert sich mit einem Zertifikat aus dem lokalen Computerspeicher. Das ist besonders für Always On VPN oder „Device Trust“ sinnvoll.
• Benutzerzertifikat (User): der Benutzer authentifiziert sich mit einem Zertifikat aus dem Benutzerzertifikatspeicher. Das kann für klassische User-VPNs passend sein.

In beiden Fällen muss der VPN-Server (Gateway) ebenfalls ein gültiges Serverzertifikat präsentieren. Windows prüft dabei die Vertrauenskette nach X.509-Regeln (PKI). Die grundlegende Spezifikation für Zertifikate und Revocation-Mechanismen ist RFC 5280.

Mindestens erforderlich

• Root-CA-Zertifikat (und ggf. Intermediate CAs) im passenden Trust Store, damit Windows dem Serverzertifikat vertraut.
• Client-Zertifikat mit Private Key (User oder Computer), damit der Client sich ausweisen kann.
• Server-Zertifikat am VPN-Gateway mit korrektem Namen (SAN/FQDN) und EKU „Server Authentication“.

Wichtige Zertifikatsattribute, die oft übersehen werden

• EKU (Enhanced Key Usage): Clientzertifikat braucht „Client Authentication“, Serverzertifikat „Server Authentication“.
• Subject/SAN: Der FQDN des VPN-Servers sollte im SAN stehen; moderne Validierung verlässt sich primär auf SAN.
• Private Key vorhanden: Ohne privaten Schlüssel kann Windows nicht signieren – das Zertifikat ist dann nutzlos für Auth.
• Revocation: CRL/OCSP müssen (je nach Policy) erreichbar sein; OCSP ist in RFC 6960 beschrieben.

Vorbereitung: Zertifikate korrekt auf Windows installieren

Der häufigste Fehler ist ein Zertifikat im falschen Speicher. Für IKEv2 gilt grob: Maschinenzertifikate gehören in „Lokaler Computer“, Benutzerzertifikate in „Aktueller Benutzer“.

Root-CA und Intermediate CAs installieren

• Root CA: „Vertrauenswürdige Stammzertifizierungsstellen“
• Intermediate CA: „Zwischenzertifizierungsstellen“

Sie können Zertifikate über die MMC installieren:

• Windows-Taste → „mmc“ starten
• Snap-In hinzufügen → „Zertifikate“
• Entweder „Computerkonto“ oder „Benutzerkonto“ wählen (je nach Ziel)

Client-Zertifikat installieren

• Maschinenzertifikat: „Zertifikate (Lokaler Computer) → Persönlich“
• Benutzerzertifikat: „Zertifikate (Aktueller Benutzer) → Persönlich“

Achten Sie darauf, dass das Zertifikat als „mit privatem Schlüssel“ importiert wird (z. B. aus einer PFX-Datei). In einer Unternehmensumgebung erfolgt das idealerweise automatisiert (AD CS Autoenrollment, Intune/MDM, SCEP/PKCS).

Schritt 1: IKEv2-VPN-Verbindung per Windows-GUI anlegen

Für ein Basis-Setup reicht das GUI oft aus. Beachten Sie: Einige fortgeschrittene IPsec-Parameter sind im GUI nicht zugänglich. Vorgehen (Windows 10/11 ähnlich):

• Einstellungen → Netzwerk & Internet → VPN
• „VPN-Verbindung hinzufügen“
• VPN-Anbieter: „Windows (integriert)“
• Verbindungsname: z. B. „Firma IKEv2“
• Servername oder -adresse: FQDN (z. B. vpn.firma.tld)
• VPN-Typ: „IKEv2“
• Anmeldeinformationstyp: abhängig von Ihrem Modell (Zertifikat, Benutzername/Passwort, Smartcard)

In vielen Umgebungen wird die zertifikatsbasierte Authentifizierung nicht komplett über dieses einfache Formular „sichtbar“. Deshalb ist PowerShell in der Praxis der zuverlässigere Weg.

Schritt 2: IKEv2-VPN per PowerShell sauber konfigurieren

PowerShell erlaubt es, Split Tunneling, DNS-Suffix und IPsec-Parameter kontrolliert zu setzen. Zentrale Cmdlets sind Add-VpnConnection und Set-VpnConnectionIPsecConfiguration. Referenz: Set-VpnConnectionIPsecConfiguration (Microsoft Learn).

Beispiel: Verbindung anlegen

PowerShell (als Administrator)
$Name = "Firma IKEv2"

$Server = "vpn.firma.tld"
Add-VpnConnection  -Name $Name

-ServerAddress $Server  -TunnelType Ikev2

-AuthenticationMethod MachineCertificate  -EncryptionLevel Required

-SplitTunneling $true  -RememberCredential

-PassThru

Hinweise:

• -AuthenticationMethod MachineCertificate setzt auf ein Maschinenzertifikat. Für Benutzerzertifikate verwenden viele Umgebungen EAP-TLS (siehe Always On VPN) oder spezifische Auth-Methoden je nach Policy.
• -SplitTunneling sollte bewusst gewählt werden. Full Tunnel ist möglich, hat aber Kapazitäts- und Policy-Folgen.

Beispiel: IPsec-Parameter härten

In der Praxis setzen Unternehmen häufig konkrete IKE/ESP-Parameter (z. B. AES-GCM, starke Integrität, DH-Gruppen), um Legacy zu vermeiden. Beispiel:

Set-VpnConnectionIPsecConfiguration `
-ConnectionName "Firma IKEv2" `
-AuthenticationTransformConstants GCMAES256 `
-CipherTransformConstants GCMAES256 `
-EncryptionMethod AES256 `
-IntegrityCheckMethod SHA256 `
-PfsGroup ECP256 `
-DHGroup ECP256 `
-Force

Welche Werte exakt passen, hängt vom VPN-Gateway ab. Wichtig ist: Client und Server müssen kompatible Proposals aushandeln können.

Schritt 3: Routen, DNS-Suffix und Namensauflösung richtig setzen

Viele „VPN geht nicht“-Tickets sind DNS- oder Routingprobleme. Wenn Sie Split Tunnel nutzen, müssen interne Netze gezielt geroutet werden und interne Namen müssen auf interne Resolver zeigen.

Routen für Split Tunnel hinzufügen

Add-VpnConnectionRoute -ConnectionName "Firma IKEv2" -DestinationPrefix "10.10.0.0/16"
Add-VpnConnectionRoute -ConnectionName "Firma IKEv2" -DestinationPrefix "10.20.0.0/16"

DNS-Suffix setzen

Ein DNS-Suffix hilft, interne Hostnamen (z. B. „intranet“) korrekt zu FQDNs zu ergänzen. Viele Umgebungen setzen dies direkt bei der Verbindung oder via MDM/Policy. In Always On VPN ist das besonders üblich (siehe Microsoft Learn Tutorial unten).

Always On VPN als professioneller Standard auf Windows

Wenn Sie den Windows-VPN-Client nicht nur „manuell“ konfigurieren, sondern zentral ausrollen und automatisiert verbinden lassen wollen, ist Always On VPN der typische Weg. Microsoft beschreibt das Vorgehen in den Tutorials:

• Create Always On VPN Connection on Windows Client Devices
• Deploy Always On VPN Infrastructure

Always On VPN wird häufig mit IKEv2 und Zertifikaten (Computer- oder Benutzerzertifikat, oft EAP-TLS) betrieben. Der Vorteil: zentrale Steuerung (MDM/GPO), klare Profile, bessere Betriebskonsistenz.

User VPN vs. Device VPN

• User VPN: Verbindung wird im Benutzerkontext aufgebaut (nach Login). Gut für klassische Remote Work.
• Device VPN: Verbindung steht schon vor dem Benutzerlogin (für Management, Always-On-Management-Kanäle, Autopilot/Intune-Workflows).

Typische Stolperfallen bei Windows IKEv2 mit Zertifikaten

Die meisten Fehler lassen sich auf wenige Ursachen zurückführen. Diese Liste sparen Ihnen in der Praxis Stunden.

Falscher Zertifikatsspeicher

• Gateway erwartet Maschinenzertifikat, aber Client hat nur Benutzerzertifikat (oder umgekehrt).
• Zertifikat ist korrekt, liegt aber im falschen Store (User statt LocalMachine).

Unvollständige Trust Chain

• Root/Intermediate CA fehlen auf dem Client.
• Server sendet die Kette nicht vollständig, Client kann nicht validieren.

EKU/Template falsch

• Clientzertifikat ohne „Client Authentication“
• Serverzertifikat ohne „Server Authentication“

Name passt nicht zum Zertifikat

• Windows verbindet zu vpn.firma.tld, aber Serverzertifikat enthält nur einen anderen Namen (SAN fehlt).

Revocation-Checks schlagen fehl

• CRL/OCSP nicht erreichbar (z. B. im Full Tunnel ohne Internet oder in restriktiven Netzen).
• Ergebnis kann je nach Policy „Handshake fail“ sein.

Troubleshooting: Die wichtigsten Windows-Fehlercodes und wo Sie nachsehen

Windows liefert bei IKEv2-Problemen häufig wiederkehrende Fehlercodes. Microsoft hat eine eigene Troubleshooting-Seite für Always On VPN, die auch für IKEv2-Clients sehr hilfreich ist: Problembehandlung bei Always On VPN (Microsoft Learn).

Fehler 809: Tunnel kann nicht aufgebaut werden

• Sehr häufig sind UDP 500 oder UDP 4500 blockiert (Firewall, Provider, Cloud-Security-Group).
• NAT-T wird benötigt, aber nicht möglich.

Fehler 13801: IKE-Authentifizierungsdaten sind nicht akzeptabel

• Passt häufig zu Zertifikatsproblemen (falscher Store, falsche EKU, Trust Chain, abgelaufenes Zertifikat).
• Auch falsche Identitäten/IDs am Gateway können eine Rolle spielen.

Wo finden Sie Logs auf Windows?

• Ereignisanzeige: Anwendungs- und Dienstprotokolle → Microsoft → Windows → RasClient
• RasMan: je nach Fall relevante Ereignisse
• PowerShell: Get-VpnConnection, Get-VpnConnectionIPsecConfiguration, Get-VpnConnectionRoute

Best Practices für einen sicheren Rollout

• MFA zusätzlich nutzen, wo möglich: Zertifikate sind stark, aber Identity-Policies erhöhen Sicherheit weiter (besonders für privilegierte Rollen).
• Zertifikatsmanagement: Ablaufdaten überwachen, Rotation planen, Widerruf (CRL/OCSP) testen.
• Split Tunnel bewusst: interne Netze minimal halten, DNS sauber planen, IPv6-Strategie definieren.
• Admin-Zugriff trennen: Admins über separate Profile, Bastion/Jump Host, strengere Device-Policies.
• IPsec-Proposals modern: Legacy-Fallbacks vermeiden, wenn Interop es erlaubt.
• SIEM-Integration: Auth-Events, Session-Start/Ende, Abbruchgründe und Policy-Denies zentral korrelieren.

Praxis-Checkliste: Windows IKEv2 Client mit Zertifikaten in 15 Minuten verifizieren

• Ist das Root/Intermediate im richtigen Store installiert?
• Hat das Clientzertifikat einen Private Key und die EKU „Client Authentication“?
• Liegt das Zertifikat im richtigen Store (Computer vs. User) passend zur Auth-Methode?
• Ist der Server-FQDN im SAN des Gateway-Zertifikats enthalten?
• Sind UDP 500/4500 bis zum Gateway offen (inkl. Cloud-SG/Provider)?
• Ist Split Tunnel Routing korrekt (Routen vorhanden) oder Full Tunnel inkl. DNS/Egress sauber geplant?
• Sind CRL/OCSP-Endpoints erreichbar (oder ist Policy entsprechend definiert)?
• Zeigen RasClient-Events konkrete Fehlercodes (809/13801) und lassen sich den Ursachen zuordnen?

Outbound-Links zur Vertiefung

• RFC 7296: IKEv2
• RFC 5280: X.509 Certificates and CRL Profile
• RFC 6960: OCSP
• Microsoft Learn: Set-VpnConnectionIPsecConfiguration
• Microsoft Learn: Create Always On VPN Connection on Windows Client Devices
• Microsoft Learn: Problembehandlung bei Always On VPN
• Netgate TNSR: Windows IKEv2 Remote Access Client Configuration (Praxisreferenz)

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.