AleksM 0 Geschrieben 29. Dezember 2015 Autor Melden Teilen Geschrieben 29. Dezember 2015 Dann hast du einen Fehler. ;) Aber deswegen zu behaupten es ginge nicht, geht doch etwas übers Ziel hinaus, oder? entschuldigung, ich habe nicht verstanden Zitieren Link zu diesem Kommentar
zahni 550 Geschrieben 29. Dezember 2015 Melden Teilen Geschrieben 29. Dezember 2015 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* Zitieren Link zu diesem Kommentar
AleksM 0 Geschrieben 29. Dezember 2015 Autor Melden Teilen Geschrieben 29. Dezember 2015 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. Zitieren Link zu diesem Kommentar
zahni 550 Geschrieben 29. Dezember 2015 Melden Teilen Geschrieben 29. Dezember 2015 (bearbeitet) 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 Zitieren Link zu diesem Kommentar
AleksM 0 Geschrieben 29. Dezember 2015 Autor Melden Teilen Geschrieben 29. Dezember 2015 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. Zitieren Link zu diesem Kommentar
zahni 550 Geschrieben 29. Dezember 2015 Melden Teilen Geschrieben 29. Dezember 2015 Wie Du meinst. Dann ohne mich. Zitieren Link zu diesem Kommentar
scnugg 0 Geschrieben 12. Juni 2016 Melden Teilen Geschrieben 12. Juni 2016 (bearbeitet) 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 Zitieren Link zu diesem Kommentar
AleksM 0 Geschrieben 12. Juni 2016 Autor Melden Teilen Geschrieben 12. Juni 2016 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. Zitieren Link zu diesem Kommentar
scnugg 0 Geschrieben 12. Juni 2016 Melden Teilen Geschrieben 12. Juni 2016 (bearbeitet) 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 Zitieren Link zu diesem Kommentar
AleksM 0 Geschrieben 12. Juni 2016 Autor Melden Teilen Geschrieben 12. Juni 2016 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. Zitieren Link zu diesem Kommentar
scnugg 0 Geschrieben 12. Juni 2016 Melden Teilen Geschrieben 12. Juni 2016 (bearbeitet) 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 Zitieren Link zu diesem Kommentar
AleksM 0 Geschrieben 12. Juni 2016 Autor Melden Teilen Geschrieben 12. Juni 2016 (bearbeitet) 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 Zitieren Link zu diesem Kommentar
blub 115 Geschrieben 12. Juni 2016 Melden Teilen Geschrieben 12. Juni 2016 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! Zitieren Link zu diesem Kommentar
AleksM 0 Geschrieben 12. Juni 2016 Autor Melden Teilen Geschrieben 12. Juni 2016 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. Zitieren Link zu diesem Kommentar
blub 115 Geschrieben 12. Juni 2016 Melden Teilen Geschrieben 12. Juni 2016 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! Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.