Hallo Leute,
Da ich auch an der Stelle mit "IKE-Authentifizierung-Anmeldeinformationen sind nicht akzeptabel" hänge versuche ich mich hier einmal einzuklinken, da ich wirklich hoffe des Nachts wieder von anderen Dingen träumen zu können.
Bei mir passiert exakt dasselbe. Im Lancom sieht alles sehr gut aus und der Windows 11 VPN Client bringt sofort beim Anklicken die besagte Fehlermeldung. Ich habe die Zertifikate bewusst spartanisch erstellt, so dass ich für die Lokale Identität ein FQDN (bei mir ganz simpel 1781va.intern) oder ASN CN=1781va.intern hinterlegt habe. Als X509v3 Subject Alternative Name Habe ich die Öffentliche IP , den von außen erreichbaren DNS_Namen und nochmals den internen DNS-Namen hinterlegt (Sollte hier auch noch die IP des intern vom Lancom für die Verbindung vergebenen IP Pools hinzugefügt werden?)
Der Aufbau funktioniert sowohl mit FQDN als auch mit ASN auf Lancom Seite gut. Das Problem liegt ja wenn ich es richtig verstehe auch eher an der Akzeptanz des Servers durch den Client. Die Zertifikate für CA und Client sind auf dem Client installiert, das Clientzertifikat sowohl unter Benutzer und Computer.
In der Ereignisanzeige des Clients finde ich Die RasClient Ereignisse 20221, 20222, 20223, 20224 als Informationen mit einem in meinen Augen normalem VPN-Aufbau dann gefolgt von 20291 ebenfalls als Information mit dem Inhalt "VPN-Name" erfordert Benutzereingriff" Das folgende Ereignis ist ein Fehler in RasClient mit der ID 20227 "Der Benutzer hat eine Verbindung mit dem Namen "VPN-Name" gewählt, die Verbindung konnte jedoch nicht hergestellt werden. Der durch den Fehler zurückgegebene Ursachencode lautet 13801."
Bei der Recherche zur 13801 landet man dann wieder bei den Zertifikaten.
Was könnte bei der 20291 mit dem Benutzereingriff gemeint sein?
Gibt es eine Chance herauszubekommen, was dem Windows Client am Zertifikat nicht gefällt? Mit Wireshark bin ich da kläglich gescheitert, da ich in keinem der Auth-Pakete etwas mit "cert" gefunden habe.
Im Wesentlichen habe ich die Anleitungen von @ukernchen https://uwe-kernchen.de/phpmyfaq/index. ... on_id=1393 und @geforce28 befolgt.
von @OnkelThomas kann ich sagen, dass ich:
"Es muss also zwingend das vom VPN-Router kommende Zertifikat zum angegebenen Hostnamen passen. Ich muss also für den IPv4-only-dynDNS ein extra Zertifikat erstellen und im VPN2-Container speichern."
nicht verstanden habe und dabei etwas Hilfe für "Eingeschränkte Netzwerker benötigen könnte.
Danke für eure Mühe!
Da ich auch an der Stelle mit "IKE-Authentifizierung-Anmeldeinformationen sind nicht akzeptabel" hänge versuche ich mich hier einmal einzuklinken, da ich wirklich hoffe des Nachts wieder von anderen Dingen träumen zu können.
Bei mir passiert exakt dasselbe. Im Lancom sieht alles sehr gut aus und der Windows 11 VPN Client bringt sofort beim Anklicken die besagte Fehlermeldung. Ich habe die Zertifikate bewusst spartanisch erstellt, so dass ich für die Lokale Identität ein FQDN (bei mir ganz simpel 1781va.intern) oder ASN CN=1781va.intern hinterlegt habe. Als X509v3 Subject Alternative Name Habe ich die Öffentliche IP , den von außen erreichbaren DNS_Namen und nochmals den internen DNS-Namen hinterlegt (Sollte hier auch noch die IP des intern vom Lancom für die Verbindung vergebenen IP Pools hinzugefügt werden?)
Der Aufbau funktioniert sowohl mit FQDN als auch mit ASN auf Lancom Seite gut. Das Problem liegt ja wenn ich es richtig verstehe auch eher an der Akzeptanz des Servers durch den Client. Die Zertifikate für CA und Client sind auf dem Client installiert, das Clientzertifikat sowohl unter Benutzer und Computer.
In der Ereignisanzeige des Clients finde ich Die RasClient Ereignisse 20221, 20222, 20223, 20224 als Informationen mit einem in meinen Augen normalem VPN-Aufbau dann gefolgt von 20291 ebenfalls als Information mit dem Inhalt "VPN-Name" erfordert Benutzereingriff" Das folgende Ereignis ist ein Fehler in RasClient mit der ID 20227 "Der Benutzer hat eine Verbindung mit dem Namen "VPN-Name" gewählt, die Verbindung konnte jedoch nicht hergestellt werden. Der durch den Fehler zurückgegebene Ursachencode lautet 13801."
Bei der Recherche zur 13801 landet man dann wieder bei den Zertifikaten.
Was könnte bei der 20291 mit dem Benutzereingriff gemeint sein?
Gibt es eine Chance herauszubekommen, was dem Windows Client am Zertifikat nicht gefällt? Mit Wireshark bin ich da kläglich gescheitert, da ich in keinem der Auth-Pakete etwas mit "cert" gefunden habe.
Im Wesentlichen habe ich die Anleitungen von @ukernchen https://uwe-kernchen.de/phpmyfaq/index. ... on_id=1393 und @geforce28 befolgt.
von @OnkelThomas kann ich sagen, dass ich:
"Es muss also zwingend das vom VPN-Router kommende Zertifikat zum angegebenen Hostnamen passen. Ich muss also für den IPv4-only-dynDNS ein extra Zertifikat erstellen und im VPN2-Container speichern."
nicht verstanden habe und dabei etwas Hilfe für "Eingeschränkte Netzwerker benötigen könnte.
Danke für eure Mühe!
Statistik: Verfasst von joh — Gestern, 19:00
