IKEv2 13801

[AleksM 0]

Dann hast du einen Fehler. ;) Aber deswegen zu behaupten es ginge nicht, geht doch etwas übers Ziel hinaus, oder?

entschuldigung, ich habe nicht verstanden

[zahni 521]

Du meinst es liegt an Windows 2012, wir glauben das nicht.  Du hast irgendein Problem, dass wir aus der Ferne nicht klären können.

 

Vielleicht schreibt Norbert Dir das noch auf Russisch *duck* 

[AleksM 0]

Du meinst es liegt an Windows 2012, wir glauben das nicht. 

ich habe 2012 R2 installiert und konfiguriert - mit Windows 10 geht es nicht.

ich habe 2008 R2 installiert und gleiche konfiguriert - mit Windows 10 geht es.

Unterschied ist nur zwischen Server OS. Das kann sein, dass IPsec auf 2012 R2 anderes funktioniert. Aber alles, was habe ich versucht, hat mich nicht geholfen.

Das wäre gut, wenn jemand von euch IKEv2 auf 2012 R2 selbst konfiguriert hat und jetzt benutzt.

[zahni 521]

Wie ich schon schrieb, macht kaum jemand VPN über einen Windows-Server. Dazu nimmt man dedizierte VPN-Gateways oder Router mit  VPN-Funktionen.

Schon weil man einen Windows-Server nicht  direkt an das Internet hängt.

Als VPN-Client empfehle ich übrigens eines der Produkte von NCP (die haben auch die passenden Gateways)

 

https://www.ncp-e.com/de/start.html

bearbeitet 29. Dezember 2015 von zahni

[AleksM 0]

Wie ich schon schrieb, macht kaum jemand VPN über einen Windows-Server. Dazu nimmt man dedizierte VPN-Gateways oder Router mit  VPN-Funktionen.

Schon weil man einen Windows-Server nicht  direkt an das Internet hängt.

Als VPN-Client empfehle ich übrigens eines der Produkte von NCP (die haben auch die passenden Gateways)

 

https://www.ncp-e.com/de/start.html

Jetzt diskutieren wir über Windows Server VPN Dienst.

[zahni 521]

Wie Du meinst. Dann ohne mich.

[scnugg 0]

Hallo,

 

wenn ich die Antwort-Postings hier in diesem Board so lese, muss ich mich regelmäßig darüber wundern, wie einige Experten entweder nur kurz und knapp antworten und/oder sich so mißverständlich ausdrücken, dass der Themenstarter immer wieder rückfragen muss und/oder das Thema ansich und die Kompetenz des Threadstarters in Frage stellen. Ist es denn wirklich so schwer, sich in die Lage des Fragenden hineinzuversetzen und ihn/sie zumindest ernstzunehmen? Aber bitte nicht mißverstehen, es ist nur als Verbesserungsvorschlag nett gemeint :)

 

Aber zurück zum Thema: Ich habe mich mal intensiv mit dem Thema VPN-server 2012 über L2TP und IKEv2 beschäftigt und inzwischen funktionieren alle möglichen VPN-Verbindungen vom client (Windows 10) aus. Hier eine Checkliste für Leute, die damit Probleme haben.

 

1.) Habt ihr am Zielsystem eine Fritzbox als Router? Dann prüfen, ob in der Fritzbox bereits VPN-Verbindungen erstellt sind. Diese müssen unbedingt GELÖSCHT werden. Ein einfaches Deaktivieren (Haken rausnehmen) reicht nicht. Ansonsten will nämlich die Fritzbox die ipsec-Verschlüsselung übernehmen und es kommen keine L2TP/IKEv2-Verbindungen zustande.

 

2.) Den Regkey

 

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent]

"AssumeUDPEncapsulationContextOnSendRule"=dword:00000002

 

am VPN client importieren.

 

3.) Im Router des VPN-Zielsystems die Ports 500 UDP, 4500 UDP, 1701 UDP+TCP und 443 TCP für SSTP an die lokale IP des  VPN server weiterleiten.

 

4.) Sind die beiden Dienste

• IKE- und AuthIP IPsec-Schlüsselerstellungsmodule  (IKEEXT)
• IPsec-Richtlinien-Agent (Policyagent)

gestartet?

 

5.) Hat der AD-user, mit dem man sich anmeldet, im Register "einwählen" das Recht "Zugriff gestatten" ?

 

6.) Für das Serverzertifikat: Als Zertifikatvorlage "Computer" nehmen. Im Register "Erweiterungen" => Anwendungsrichtlinien aber noch "IP-Sicherheits IKE, dazwischenliegend" hinzufügen. Im Reiter "Sicherheit" das Recht zum "Registrieren"/"Automatisch Registrieren" erteilen (sonst erscheint bei der Zertifikatregistierung nicht die duplizierte Computer-Zertifikatvorlage) und bei "Antragstellername" die Option "Informationen werden in der Anforderung angegeben" erteilen. Dann über Zertifikate=>Lokaler Computer=>Eigene Zertifikate das Zertifikat anfordern. Als CN den DynDNS-Host oder die feste IP nehmen. Ich habe den Hostnamen zusätzlich noch als "Alternativen Antragstellernamen"=>DNS-Namen eingetragen, weil ich glaube, dass das bei der L2TP-Verbindung mit Zertifikat hilfreich war. Nach der Zertifikatregistrierung dann das Serverzertifkat im IIS an Port 443 binden und im Routing und RAS unter Eigenschaften/Sicherheit/SSL-Bindung auswählen. Für L2TP mit Zertifikat ist es zusätzlich nötig, ein Clientzertifikat auszustellen und am VPN-client unter Lokaler Computer=>Eigene Zertifikate zu importieren, für SSTP ist das nicht nötig. Natürlich muss (wie auch bei SSTP) zusätzlich noch das Zertifikat der Zertifizierungsstelle (CA) am client unter "Vertrauenswürdige Stammzertifizierungsstellen" importiert werden.

 

7.) Für L2TP mit Zertifikat muss im Routing und RAS unter Eigenschaften/Sicherheit das Feld "Benutzerdefinierte IPsec Richtlinie für LTP/IKE-Verbindungen" leer bleiben, also kein Passwort eingetragen sein. Das finde ich zwar eigentlich unlogisch, denn warum soll es nicht möglich sein, L2TP sowohl mit Schlüssel als auch mit Zertifikat zu nutzen? Aber es ist leider so... Kommt bei der Verbindung der Fehler "Verarbeitungsfehler bei der ersten Sicherheitsaushandlung", dann am client in der VPN-Verbindung unter Eigenschaften/erweiterte Eigenschaften das Feld "Die Namen- und Verwendungsattribute des Serverzertifikats überprüfen" deaktivieren, also den Haken rausnehmen. Alternativ statt einer DynDNS-Adresse direkt die öffentliche IP-Adresse als VPN-Ziel in der VPN-Verbindung am client eintragen, das Serverzertifikat dann auf die öffentliche IP-Adresse als CN ausstellen und am server registrieren. Wie gesagt muss auch für den Client ein Zertifikat erstellen und dort unter Lokaler Computer=>Eigene Zertifikate importieren.

 

SSTP erfordert kein Clientzertifikat. Der Vorteil von SSTP gegenüber L2TP mit ipsec ist der schnelle File-Datentransfer (es wird fast der gesamte Upload ausgenutzt), alternativ könnte man natürlich auch FTP mit TLS nutzen, z.B. mit Filezilla server+client. Bei den IPSEC/IKE-Verbindungen ist der Filedatentransfer dagegen durchweg stark schwankend und gering, egal, ob diese Verbindungen direkt über ein Fritzbox-Profil oder aber über den VPN-server aufgebaut werden.

 

NIcht benötigte oder doppelte, zuvor testweise von der CA ausgestellte Zertifikate aus dem Zertifikatspeicher "Lokaler Computer/Eigene Zertifikate" löschen. Kommt die VPN-Verbindung zustande, jedoch ist ein Anpingen oder RDP nicht möglich, dann den server neu starten.

 

So, nun hoffe ich, dass meine Informationen einigen usern bei der Herstellung von VPN-Verbindungen zu einem Routing und RAS-Server helfen können, damit es schneller geht als bei mir (3 Tage Arbeit...)

Hope this helps..
 

:) 

bearbeitet 12. Juni 2016 von scnugg

[AleksM 0]

Hallo scnugg. Danke für deine Antwort.

Aber in diesem Thema wird nur IKEv2 besprochen. Es gibt kein Problem mit L2TP. Aber es gibt ein Problem mit IKEv2, egal ob den Klient hinten Router oder nicht ist. Erstmal läuft es, nach dem Neustart von Server - läuft nicht mehr.

Vorgestern habe ich auf 2016 TP5 getestet - das gleiche Problem.

[scnugg 0]

Hi,

 

ja, aber L2TP und IKE haben für die Konfiguration viel Gemeinsamkeit und deswegen wollte ich das Ganze mal komplett zusammenfassen. Vielleicht möchten ja auch einige user beide Methoden mal ausprobieren.

 

Hier einige Vorschläge:

 

Hast Du denn schon mal für VPN-Verbindung und serverzertifikat statt des DynDNS-Hosts direkt die öffentliche IP-Adresse eingetragen und es damit probiert?

 

Ich würde auch mal bei der Zertifikatregistrierung den Host nicht nur als CN, sondern zusätzlich auch als Alternative Antragstellername/DNS-Name eintragen.

 

Sind alle 3 Eigenschaften Serverauth/Clientauth und "IP-Sicherheits IKE, dazwischenliegend" in Deinem Computerzertifikat?

 

Ich werde jetzt mal meine IKE-Verbindung 1 Stunde halten und dann schauen, ob sie ebenfalls einbricht....

bearbeitet 12. Juni 2016 von scnugg

[AleksM 0]

IKEv2 läuft nur mit den DNS Name. Ich nutze gleichen Typ von Zertifikat, wie auf 2008 R2.

Ich werde jetzt mal meine IKE-Verbindung 1 Stunde halten

 

 

Neustart der Server und verbinde wieder IKEv2.

[scnugg 0]

IKEv2 läuft nur mit den DNS Name. Ich nutze gleichen Typ von Zertifikat, wie auf 2008 R2.

 

Neustart der Server und verbinde wieder IKEv2.

Also soll ich mal testweise jetzt meinen VPN-server neustarten, dann IKEv2 verbinden und schauen, wie lange die VPN-Verbindung hält?

 

Wie wäre es, wenn Du Deinen server virtualisierst und dann z.B. vom Hyper-V Hoster aus eine VPN-Verbindung zum virtuellen server aufbaust? Damit könntest Du prüfen, ob das Problem beim Router vorliegt. Ich selber konnte auf diese Weise Probleme mit den VPN-Verbindungen ganz gut analysieren.

bearbeitet 12. Juni 2016 von scnugg

[AleksM 0]

Also soll ich mal testweise jetzt meinen VPN-server neustarten, dann IKEv2 verbinden und schauen, wie lange die VPN-Verbindung hält?

genau und zeig uns biite die Printscreens von VPN wie:

 

Damit könntest Du prüfen, ob das Problem beim Router vorliegt

 

es gibt kein Router zwischen den Server und Klient. Server und Klient für Test ins gleiche Netz sich befinden. Beide sind auf Hyper-V

bearbeitet 12. Juni 2016 von AleksM

[blub 115]

Lt. deinem erstem Screenshot erlaubst du auch die EAP und MS-CHAP2 Protokolle zur Authentication. Das sind Asbach-Uralt Protokolle aus Window2000 Zeiten. Nimm das mal raus, ebenso wie den Preshared Key.

Falls die Verbindung anschließend noch aufgebaut wird, bist du erstmal sicher, dass vernünftiges IKE verwendet wird.

 

Kann schon sein, dass MS-Chap eine Lifetime für den Key implementiert hat und Windows2012 keinen neuen Key aus SecurityGründen mehr ausstellen will. Ist aber Spekulation!

[AleksM 0]

erstem Screenshot erlaubst du auch die EAP und MS-CHAP2 Protokolle zur Authentication. Das sind Asbach-Uralt Protokolle aus Window2000 Zeiten.

 

Es ist der arbeitende Server 2008 R2 als Beispiel.

[blub 115]

Es ist der arbeitende Server 2008 R2 als Beispiel.

a-tens ) bist du sicher, dass IKE auf dem 2008R2 verwendet wird und nicht MS-CHAP2?

b-tens) Im Handling von alten, unsicheren Protokollen unterscheiden sich Betriebssystemversionen natürlich.

 

BTW: De Tipp weiter oben von Norbert mit "Wireshark" war übrigens ein guter Tipp!