Win10 VPN Client zu Lancom

[geforce28]

Hallo zusammen,

ich habe meinen alten Router 1781ef+ gegen einen neuen Router 1900ef getauscht.
Der alte Router hatte noch die LCOS 10.40 RU2...

Mit dem neuen Router bin ich jetzt auf 10.50 RU9 gestartet und habe mich dazu entschlossen keinen Config Import zu machen, sondern alles sauber neu einzurichten

Jetzt scheitere ich daran ein zertifikatbasiertes IKEv2 VPN für einen Win10 Client (in WIN integriertes VPN) hinzubekommen.
Wie bin ich vorgegangen.

1) In XCA eine Datenbank erstellt.
2) Root-CA generiert mit Vorlage "default CA" - Common Name den externen-FQDN Namen des Lancom Routers genommen, RSA 2048 bit schlüssel, 10 Jahre Gültigkeit, SAN ebenso den externen-FQDN Namen des Lancom Routers...
3) Server-Zertifikat für den Lancom in XCA erstellt. - Vorlage "default TLS_Server", Root-ca unterschreiben lassen, Common Name den externen-FQDN Namen des Lancom Routers genommen, privaten schlüssel generiert, SAN ebenso externen-FQDN, Gültigkeit 9 Jahre.
4) Client-Zertifikat mit XCA erstellt. - Vorlage "default TLS_Client", Root-ca unterscheiben lassen, Common Name habe ich einen frei definierten Clientnamen, in meinem Fall "IKEV2_C1" genommen; privaten schlüssel generiert, Gültigkeit 9 Jahre.
5) Root-Ca Zertifikat als PEM (crt) exportiert, die anderen beiden Zertifikate als PKCS#12 (pfx) exportiert.
6) Server Zertifkat in den Lancom Router in VPN1 Container geladen.
7) IKEv2 VPN per Assistent eingerichtet (1 Click), danach im Lanconfig die Parameter für die Verschlüsselung angepasst (DH14, DH19; PFS JA; IKE-SA AES-CBC-256, AES-GCM-256; Hash-Liste SHA-256; Child-CA AES-CBC-256, AES-GCM-256; Hash Liste Sha-256)
In der Authentifizierung für den Client auf RSA-Signature und ASN.1 Distinguished gestellt...
8.1) Lokale Identität CN=externer-FQDN
8.2) Entfernte Identität CN=IKEV2_C1
8.3) Lokales Zertifikat: VPN1

9) In Windows das Client Zertifikat Importiert in den Computerspeicher.
10) Das Root-Ca importiert in den Computerspeicher unter "vertrauenswürdige Stammzertifizierungsstellen".
11) Add-VPNConnection -Name "VPN-NAME" -ServerAddress externer-FQDN -TunnelType "Ikev2" -AuthenticationMethod MachineCertificate -DnsSuffix test.domain -EncryptionLevel Required -SplitTunneling $False –PassThru
12) Set-VpnConnectionIPsecConfiguration -ConnectionName "VPN-NAME" -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES256 -DHGroup Group14 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -PfsGroup PFS2048 –PassThru


Wenn ich mich dann versuche mit dem Windows Client per VPN zu verbinden, sieht es auf Lancom Seite (VPN-Debug Trace) so aus, als würde alles gut gehen. Authentifizierung / Aushandlung, alles gut, Lancom sagt sogar am Ende Connected und es sieht so aus, als würde alles funktionieren.

Der Windows Client gibt jedoch direkt die Fehlermeldung "IKE-Authentifizierung-Anmeldeinformationen sind nicht akzeptabel".


Habt ihr eine Idee, was ich falsch gemacht haben könnte ?
Ich habe das Konstrukt eigentlich auf genau die gleiche Art und Weise auf dem alten Router erfolgreich am laufen...

[Barbarossa]

Ich habe die Erfahrung gemacht, dass die lokale Identität auf dem Router als FQDN besser funktioniert, sofern du den im Zertifikat mit drin hast. Mit dem ASN.1-Distinguished-Name hab ich immer wieder Probleme gehabt.

Man kann im Lancom Trace auch ganz gut sehen, Welcher String tatsächlich als Identität übermittelt wird, ob das "CN=" drin vorkommt usw.

[GrandDixence]

Die Fehlermeldung ist eindeutig. Der VPN-Client akzeptiert das vom VPN-Server (LANCOM-Router) präsentierte X.509-Zertifikat nicht. Die Authentifizierung erfolgt beim VPN-Tunnelaufbau mit dem dritten und vierten IKE-Telegramm (IKE_AUTH). Empfängt der LANCOM-Router (trace vpn-ike oder ähnlich) das dritte IKE-Telegramm, so war die Verhandlung des Schlüsselmaterials für die verschlüsselte Kommunikation im Steuerkanal (IKE) erfolgreich. Versendet der LANCOM-Router das vierte IKE-Telegramm, so hat er das vom VPN-Client präsentierte X.509-Zertifikat akzeptiert. Ob der VPN-Client das vom VPN-Server präsentierte X.509-Zertifikat akzeptiert hat, ist erst nach dem VPN-Tunnelaufbau erkennbar. Siehe auch:
fragen-zum-thema-vpn-f14/ikev2-ueber-ea ... ml#p111243

Werden alle Anforderungen an das X.509-Zertifikat erfüllt? Alle erforderlichen "X509v3 extensions" vorhanden? Siehe dazu:
fragen-zum-thema-vpn-f14/vpn-via-androi ... tml#p97795

Immer häufiger wird die Verwendung des SAN gefordert. Google sei dank! Siehe dazu:
https://www.heise.de/hintergrund/Chrome ... 17594.html

https://support.mozilla.org/en-US/questions/1379667

Vielleicht ist hier der einfachste Weg der Fehlersuche die Realisierung des verschlüsselten Zugriffs (HTTPS) auf das Webinterface vom LANCOM-Router. Wenn in einem strengen Webbrowser, wie Firefox ESR 102, der Aufruf der Login-Webseite des Webinterface vom LANCOM-Router einwandfrei funktioniert, liegt wohl ein anderes Problem vor.

[geforce28]

Guten Morgen.

Sorry habe das Thema, aufgrund Zeitmangels jetzt länger nicht mehr verfolgt.
Es ist aber noch immer nicht gelöst

Die Anforderungen an die Zertifikate sind selbstverständlich erfüllt. Auch SAN ist drin..

Was mich ja so stark verwundert ist, dass es mit der LCOS 10.40 alles funktioniert hat...

Noch jemand eine Idee ?

[OnkelThomas]

Ich hatte bisher schon zertifikatsbasiertes IKEv2 für Android mit strongSwan im Einsatz und wollte es jetzt auch mal mit Windows >= 22H2 (davor sind wohl noch Registry-Hacks nötig) versuchen. Ich hab Ihre Anleitung ab Punkt 7) befolgt und es hat in einer VirtualBox-Testumgebung funktioniert. (Wobei ich als einen Punkt 13) noch mit 'Add-VpnConnectionRoute -ConnectionName "VPN-NAME" -DestinationPrefix 192.168.0.0/24 -AllUserConnection -PassThru' das Routing eingeengt habe.)
"Vorort" hat es dann zunächst nicht funktioniert. Der Client hat "Verbunden" gemeldet und auch per CFG seine Daten erhalten, aber es floss kein Traffic. Mein Verdacht ging auf IPv4-in-IPv6-Kapselung. Also habe ich geschwind in C:\Windows\System32\drivers\etc\hosts die IPv4 für den VPN-Router-FQDN hinterlegt. Dann lief es.
Nach dem Ändern des Hostnamen/VPN-Router-FQDN in den Windows-VPN-Einstellungen, auf einen IPv4-only-dynDNS-Name kam dann:
"IKE-Authentifizierung-Anmeldeinformationen sind nicht akzeptabel". (Also genau Ihr Problem.)
Was auch Sinn macht, da man, anderes wie bei den meisten anderen Clients, dem nativen Windows-VPN-Client keinen erwarteten CN vorgeben kann. 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.

Nochmal sicher gehen das der "externen-FQDN" genau dem CN im Zertifikat entspricht und dass die CA auch wirklich in "Vertrauenswürdige Stammzertifizierungstellen" des Windows-Systems liegt. Auch auf dem Router mit

Code: Alles auswählen

show vpn ca
show vpn cert

prüfen ob auch wirklich die erwarteten CAs/Zertifikate da sind.

Ansonsten muss es gehen, ich hab schließlich Ihre Anleitung befolgt.

[joh]

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!

[joh]

Ja, kann als erledigt angesehen werden.
Nachdem ich erneut fragen-zum-thema-vpn-f14/windows-phone- ... 15356.html gelesen hatte habe ich festgestellt, dass ich die TLS Web Client Authentication im Zertifikat vergessen hatte, sondern aus der generellen XCA Vorlage nur die Server Authentication genommen hatte. Komme mir gerade sehr dähmlich vor, bin aber trotzdem glücklich, dass es jetzt funktioniert.