nach dem Verlust zweier kompletter Arbeitstage brauche ich Hilfe:
Wir haben in der Zentrale einen Lancom 1793VA mit LCOS 10.42RC. Dieses Gerät ist direkt per DSL mit dem Internet verbunden und per DNS erreichbar (es handelt sich "fast" um eine statische IP - diese ist zwar dynamisch, wechselt aber sehr selten).
Wir möchten von einem Client mit Windows 10 Enterprise 1909 von einer Filiale aus ein VPN zu dem 1793VA in der Zentrale aufbauen. Der betreffende Client-Rechner befindet sich hinter einem Router und ist per NAT ans Internet angebunden (das spielt für das Problem aber vermutlich keine Rolle, siehe unten). Der Router in der Filiale besitzt ebenfalls eine selten wechselnde öffentlich IP-Adresse und ist ebenfalls per DNS erreichbar. Das VPN soll mithilfe des in Windows integrierten IPSec-Clients über IKEv2 aufgebaut werden, und zwar mithilfe von Maschinen-Zertifikaten (also ohne Benutzer- und Paßwort-Eingabe).
Ich habe mir entsprechende Anleitungen mehrmals und gründlich durchgelesen, unter anderem die von GrandDixence hier im Forum. Leider scheitert bereits der Aufbau des Tunnels. Was auch immer ich tue, sofort beim Aufbau der VPN-Verbindung vom Windows-Client in der Filiale aus erscheinen im VPN-Trace des 1793VA in der Zentrale stets die Meldungen:
Code: Alles auswählen
[VPN-Debug] 2020/09/30 10:41:11,386
Peer <UNKNOWN>: Received an IKE_SA_INIT-REQUEST of 632 bytes
Gateways: ip.adresse.der.zentrale:500<--ip.adresse.der.filiale:61946
SPIs: 0xEACDA82CE78257330000000000000000, Message-ID 0
Payloads: SA, KE, NONCE, NOTIFY(IKEV2_FRAGMENTATION_SUPPORTED), NOTIFY(DETECTION_SOURCE_IP), NOTIFY(DETECTION_DESTINATION_IP), VENDOR, VENDOR, VENDOR, VENDOR
QUB-DATA: ip.adresse.der.zentrale:500<---ip.adresse.der.filiale:61946 rtg_tag 0 physical-channel WAN(1)
transport: [id: 77053, UDP (17) {incoming unicast, fixed source address}, dst: ip.adresse.der.filiale, tag 0 (U), src: ip.adresse.der.zentrale, hop limit: 64, DSCP: CS6, ECN: Not-ECT, pmtu: 1492, iface: T-ONLINE (5), mac address: ff:ff:ff:ff:ff:ff, port 0], local port: 500, remote port: 61946
LCVPEI: IKE-R-No-rule-matched-ID
IKE-TRANSPORT freed
[VPN-Status] 2020/09/30 10:41:11,386
Peer <UNKNOWN>: Received an IKE_SA_INIT-REQUEST of 632 bytes
Gateways: ip.adresse.der.zentrale:500<--ip.adresse.der.filiale:61946
SPIs: 0xEACDA82CE78257330000000000000000, Message-ID 0
-Could not assign message from ip.adresse.der.filiale to any existing peer.
-Either Peer's remote gateway is unspecified/unresolved by DNS, or
-IKEv2 message came through unexpected interface, or
-DEFAULT peer is not active
Deshalb die erste allgemeine und von der konkreten Konfiguration unabhängige Frage: Mit welchen Mechanismen ordnet der Router eingehende IKEv2-Pakete den definierten Peers zu? Muß ich die Peers im Lancom noch woanders definieren als auf den Konfigurations-Seiten unter "IKEv2" (in LANconfig)?
Nun zur Konfiguration des Windows-Clients: Wir haben ein Zertifikat erzeugt und in den Windows-Zertifikatsspeicher importiert, und zwar in
Code: Alles auswählen
Certificates (Local Computer) -> Personal
Des weiteren befindet sich im Windows-Zertifikatsspeicher im Root-Trust das Zertifikat, von dem obiges Zertifikat signiert worden ist. Dieses Root-Zertifikat befindet sich ebenso im 1793VA in der Zentrale. Das Device-Zertifikat und das Peer-Zertifikat des 1793VA sind ebenfalls von diesem Root-Zertifikat signiert, und dieses ist im 1793VA auch als CA-Zertifikat hinterlegt.
Die betreffende VPN-Verbindung selbst habe ich in Windows mithilfe von Powershell angelegt und konfiguriert (weil die Oberfläche die Verschlüsselungs-Optionen nicht zur Verfügung stellt):
Code: Alles auswählen
Add-VpnConnection -AllUserConnection -AuthenticationMethod MachineCertificate -EncryptionLevel Required -Name Test -ServerAddress vpn.zentrale.de -TunnelType Ikev2
Set-VpnConnectionIPsecConfiguration -ConnectionName Test -AuthenticationTransformConstants GCMAES256 -CipherTransformConstants GCMAES256 -EncryptionMethod GCMAES256 -IntegrityCheckMethod SHA384 -PfsGroup none -DHGroup Group14 -AllUserConnection -Verbose
Zur Router-Konfiguration:
Als Gateway ist hier vpn.filiale.de eingetragen. Der Trace auf dem Router zeigt auch, daß dieser DNS-Name zur korrekten Adresse aufgelöst wird. Eventuell mache ich bei den Auth-Einstellungen etwas falsch:
Als Local Identifier steht hier /CN=vpn.zentrale.de und als Remote Identifier /CN=vpn.filiale.de.
Im Slot VPN1 ist das Peer-Zertifikat des 1793VA hinterlegt. Als Subject hat es /CN=vpn.filiale.de, allerdings hat es keine Felder für subjectAltName und ExtendedKeyUsage. Es ist mit dem gleichen Root-Zertifikat signiert wie alles andere.
Anscheinend kann man hier nur 3 Attachments pro Post hochladen, deshalb kurz noch per Beschreibung: In den Encryption Settings (PP_ENCRYPTION) habe ich ALLE Haken gesetzt, so daß Windows und der 1793VA auf einen gemeinsamen Nenner kommen (das reduziere ich später natürlich wieder, wenn der Verbindungsaufbau jemals gelingt). Alle anderen Felder bzw. weiteren Dialogboxen im Bereich VPN -> IKEv2/SIPSec in LANconfig habe ich auf den Voreinstellungen belassen.
Und das beste zum Schluß: Zum Testen habe ich in der Filiale statt des vorhandenen Routers eine Linux-Box mit StrongSwan aufgestellt. Es hat ungefähr 15 Minuten gebraucht, bis das Windows-Client-Zertifikat dort installiert war und entsprechende Einstellungen gemacht waren - der Tunnel von StrongSwan zum 1793VA baute sich damit auf Anhieb auf.
Hat jemand einen Tip, warum der Lancom ums Verrecken die von Windows eingehenden Pakete der konfigurierten Verbindung nicht zuordnen kann?
Viele Grüße und besten Dank,
Agamemnon