Keine IKEv2-Verbindung zu 1793VA möglich (eingehende IKEv2-Pakete können keinem Peer zugeordnet werden)

Forum zum Thema allgemeinen Fragen zu VPN

Moderator: Lancom-Systems Moderatoren

Antworten
Agamemnon
Beiträge: 11
Registriert: 12 Dez 2019, 19:33

Keine IKEv2-Verbindung zu 1793VA möglich (eingehende IKEv2-Pakete können keinem Peer zugeordnet werden)

Beitrag von Agamemnon »

Hallo zusammen,

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
Offensichtlich kann das eingehende Paket im Router keinem der definierten Peers zugeordnet werden. Ich bin recht sicher, daß dieser Fehler noch gar nichts mit etwaigen Problemen durch NAT oder ähnliche Störfaktoren zu tun hat: Der 1793VA sendet ja noch nicht mal ein Paket zurück (wie auch, wenn er gar nicht weiß, welcher seiner konfigurierten VPN-Verbindungen er das eingehende Paket überhaupt zuordnen soll).

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
Dieses Zertifikat sollte von Windows beim Aufbau einer Verbindung verwendet werden können: Der DN / das subject ist von der Form /CN=vpn.filiale.de, es ist ein subjectAltName enthalten (DNS: vpn.filiale.de), die KeyUsage ist korrekt festgelegt (critial, Key Encipherment, Digital Signature), und die extendedKeyUsage ebenfalls (Server Authentication) - siehe Screenshot. vpn.filiale.de ist natürlich der DNS-Name, unter dem der Router in der Filiale erreichbar ist, d.h. der DNS-Name, der aus Sicht des Routers in der Zentrale der Absender-IP-Adresse der eingehenden IKEv2-Pakete entspricht.
Zertifikats-Eigenschaften.png
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
Hierbei ist vpn.zentrale.de natürlich der DNS-Name, der zur öffentlichen IP-Adresse des 1793VA in der Zentrale auflöst.

Zur Router-Konfiguration:
Connection
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:
Authentication
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
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
GrandDixence
Beiträge: 1054
Registriert: 19 Aug 2014, 22:41

Re: Keine IKEv2-Verbindung zu 1793VA möglich (eingehende IKEv2-Pakete können keinem Peer zugeordnet werden)

Beitrag von GrandDixence »

Filiale UND Zentrale müssen dynamisches DNS einsetzen. Auf beiden VPN-Endpunkte muss unter:

/Setup/VPN/IKEv2/Gegenstellen/Entferntes-Gateway

der DNS-Name des anderen VPN-Endpunktes eingetragen werden. Entweder wird im genannten LCOS-Menükonfigurationspunkt die statische IP-Adresse des anderen VPN-Endpunktes eingetragen oder es ist bei dynamischen IP-Adressen der DNS-Name des anderen VPN-Endpunktes einzutragen (dynamisches DNS). Namensauflösung der Filiale UND Zentrale kontrollieren:

https://www.heise.de/netze/tools/dns/
=> Hostname to Address Lockup IPv4 (A Record)

Der VPN-Endpunkt interessiert sich beim IKE_SA_INIT noch nicht für die Authentifizierung. Somit ist das Maschinenzertifikat (noch) egal.

Hinweis: Aktuelles LCOS aus dem Stable-Zweig einsetzen (LCOS 10.42 macht im VPN-Bereich Probleme...)
https://www.lancom-systems.de/produkte/ ... ebersicht/
Agamemnon
Beiträge: 11
Registriert: 12 Dez 2019, 19:33

Re: Keine IKEv2-Verbindung zu 1793VA möglich (eingehende IKEv2-Pakete können keinem Peer zugeordnet werden)

Beitrag von Agamemnon »

Erst einmal vielen Dank für Deine Mühe und die Antwort!
GrandDixence hat geschrieben: 30 Sep 2020, 20:17 Filiale UND Zentrale müssen dynamisches DNS einsetzen. Auf beiden VPN-Endpunkte muss unter:

/Setup/VPN/IKEv2/Gegenstellen/Entferntes-Gateway

der DNS-Name des anderen VPN-Endpunktes eingetragen werden.
In der Filiale steht ein anderer Router (nicht von Lancom), der aber IPSEC passieren läßt. In der Filiale soll das VPN von einem Client-Rechner aus aufgebaut werden, mithilfe des in Windows integrierten VPN-IPSec-Clients, über IKEv2 und Maschinen-Zertifikate (das ging im langen Text meiner Frage wohl unter).

In der VPN-Verbindung von Windows habe ich als Gegenstelle natürlich den Dyndns-Namen des 1793VA der Zentrale eingetragen. Das erste Paket kommt ja auch auf dem Lancom der Zentrale an ...
GrandDixence hat geschrieben: 30 Sep 2020, 20:17 Entweder wird im genannten LCOS-Menükonfigurationspunkt die statische IP-Adresse des anderen VPN-Endpunktes eingetragen oder es ist bei dynamischen IP-Adressen der DNS-Name des anderen VPN-Endpunktes einzutragen (dynamisches DNS). Namensauflösung der Filiale UND Zentrale kontrollieren:
Das ist genau das Problem: Beide Parteien sind per DNS erreichbar, d.h. beide haben einen Dyndns-Namen, unter dem sie auch ordnungsgemäß erreichbar sind; zum Beispiel kann man sie damit anpingen.
GrandDixence hat geschrieben: 30 Sep 2020, 20:17 Der VPN-Endpunkt interessiert sich beim IKE_SA_INIT noch nicht für die Authentifizierung. Somit ist das Maschinenzertifikat (noch) egal.
Super, danke für die Erklärung. Ich hatte das auch bereits vermutet, war aber nicht sicher. Diese Information ist sehr hilfreich.
GrandDixence hat geschrieben: 30 Sep 2020, 20:17 Hinweis: Aktuelles LCOS aus dem Stable-Zweig einsetzen (LCOS 10.42 macht im VPN-Bereich Probleme...)
https://www.lancom-systems.de/produkte/ ... ebersicht/
Das ist nun wohl die einzige Möglichkeit. Ich werde das versuchen und hoffe, daß ein Downgrade keine Probleme bereitet. Der 1793VA in der Zentrale wird produktiv genutzt ... ich werde berichten.

Viele Grüße und vielen Dank,

Agamemnon
Agamemnon
Beiträge: 11
Registriert: 12 Dez 2019, 19:33

Re: Keine IKEv2-Verbindung zu 1793VA möglich (eingehende IKEv2-Pakete können keinem Peer zugeordnet werden)

Beitrag von Agamemnon »

OK, das Downgrade hat einwandfrei funktioniert, der Router läuft wie vorher. Es ist nun die Version 10.40RU2 aufgespielt.

Leider hat die Aktion bezüglich meines Problems überhaupt nichts gebracht. Um das Problem nochmals zu verdeutlichen, hier ein Auszug aus dem VPN-Trace des 1793VA in der Zentrale:

Code: Alles auswählen

[VPN-Status] 2020/10/01 08:15:30,174
starting external DNS resolution for ROTH_CONN
IpStr=>vpn.filiale.de<, IpAddr(old)=79.192.36.180, IpTtl(old)=60s

[VPN-Status] 2020/10/01 08:15:30,196
external DNS resolution for ROTH_CONN
IpStr=>vpn.filiale.de<, IpAddr(old)=79.192.36.180, IpTtl(old)=60s
IpStr=>vpn.filiale.de<, IpAddr(new)=79.192.36.180, IpTtl(new)=60s
und dann trotzdem, sobald das erste IKEv2-Paket des Windows-Clients aus der Filiale eingeht:

Code: Alles auswählen

[VPN-Status] 2020/10/01 08:06:42,367
Peer <UNKNOWN>: Received an IKE_SA_INIT-REQUEST of 632 bytes
Gateways: 79.192.38.43:500<--79.192.36.180:62691
SPIs: 0x86106C4C067C99260000000000000000, Message-ID 0
-Could not assign message from 79.192.36.180 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
Der 1793VA in der Zentrale kann also den Dyndns-Namen der Filiale auflösen und trotzdem das von dort eingehende Paket keiner konfigurierten VPN-Verbindung zuordnen.

ROTH_CONN ist im Moment die einzige aktivierte Verbindung auf dem 1793VA in der Zentrale, und dort ist vpn.filiale.de als entferntes Gateway hinterlegt!

Das gleiche Problem tritt übrigens sogar dann auf, wenn ich in der Verbindung ROTH_CONN als entferntes Gateway direkt die IP-Adresse der Filiale eingebe. Sogar dann kann das eingehende IKEv2-Paket, das ja genau von dieser Adresse aus gesendet worden ist, keiner Verbindung zugeordnet werden.

Ich bin jetzt absolut ratlos. Welchen Weg gibt es noch, die IP-Adresse des eingehenden Pakets einer Verbindung zuzuordnen?
Agamemnon
Beiträge: 11
Registriert: 12 Dez 2019, 19:33

Re: Keine IKEv2-Verbindung zu 1793VA möglich (eingehende IKEv2-Pakete können keinem Peer zugeordnet werden)

Beitrag von Agamemnon »

Noch ein anderer Teil des VPN-Trace:

Code: Alles auswählen

[VPN-Debug] 2020/10/01 08:27:17,438
Peer <UNKNOWN>: Received an IKE_SA_INIT-REQUEST of 632 bytes
Gateways: 79.192.38.43:500<--79.192.36.180:62909
SPIs: 0x31DB666EB08E1E680000000000000000, 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: 79.192.38.43:500<---79.192.36.180:62909 rtg_tag 0 physical-channel WAN(1)
transport: [id: 7744, UDP (17) {incoming unicast, fixed source address}, dst: 79.192.36.180, tag 0 (U), src: 79.192.38.43, 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: 62909
LCVPEI: IKE-R-No-rule-matched-ID
IKE-TRANSPORT freed
Hier ist vor allem die Zeile

Code: Alles auswählen

LCVPEI: IKE-R-No-rule-matched-ID
aufschlußreich. Ich kann mir vorstellen, was sie bedeutet, aber das hilft mir nicht weiter, wenn ich nicht weiß, wie man die entsprechenden Regeln anlegt. Kann mir jemand bezüglich dieser Meldung weiterhelfen?

Viele Grüße und vielen Dank,

Agamemnon
GrandDixence
Beiträge: 1054
Registriert: 19 Aug 2014, 22:41

Re: Keine IKEv2-Verbindung zu 1793VA möglich (eingehende IKEv2-Pakete können keinem Peer zugeordnet werden)

Beitrag von GrandDixence »

Agamemnon hat geschrieben: 01 Okt 2020, 08:25OK, das Downgrade hat einwandfrei funktioniert, der Router läuft wie vorher. Es ist nun die Version 10.40RU2 aufgespielt.
Downgrade auf den Stable-Zweig bedeutet aktuell ein Downgrade auf LCOS 10.34 RU1!
Der Einsatz von LCOS-Versionen > 10.34 ist zur Zeit für den produktiven Einsatz nicht empfohlen.
https://www.lancom-systems.de/produkte/ ... ebersicht/

Über VPN-Probleme mit LCOS-Versionen > 10.34 findet man hier genügend Berichte. Zum Beispiel:
fragen-zum-thema-vpn-f14/probleme-mit-v ... 18375.html

Meine (wenigen) VPN-Tunnels mit dynamischen IP-Adressen auf beiden Seiten funktionieren mit LCOS 10.34 RU1 einwandfrei.

Alternativ kann auch mit dem DEFAULT Peer gearbeitet werden. Aber aus Sicherheitsgründen ist der Einsatz des DEFAULT Peer's nicht zu empfehlen:

Mit einem DEFAULT-Eintrag in /Setup/VPN/IKEv2/Gegenstellen/ kann jeder mit dem Internet verbundener Netzwerkteilnehmer ein IKE_SA_INIT-REQUEST an den LANCOM-Router senden UND dieses IKE_SA_INIT-REQUEST wird vom LANCOM-Router verarbeitet. Auch ein böswilliger Hacker kann dank dem Default Peer IKE_SA_INIT-Requests an den LANCOM-Router senden und damit eventuell vorhandene Sicherheitslücken im LANCOM-Router ausnutzen. Oder der böswillige Hacker kann den LANCOM-Router mit zahlreichen IKE_SA-INIT-Requests fluten (=> DoS-Attacke).
fragen-zum-thema-vpn-f14/sitetosite-vpn ... tml#p91268

https://de.wikipedia.org/wiki/Denial_of_Service

Bei fehlendem DEFAULT-Eintrag in /Setup/VPN/IKEv2/Gegenstellen/ verarbeitet das VPN-Modul des LANCOM-Router nur einkommende IKE_SA_INIT-REQUEST's, deren Absender-IP-Adresse in /Setup/VPN/IKEv2/Gegenstellen/Entferntes-Gateway eingetragen sind (=> statische IP-Adressen) ODER für welche die Absender-IP-Adresse einer in /Setup/VPN/IKEv2/Gegenstellen/Entferntes-Gateway eingetragen DNS-Adresse entspricht (=> dynamische IP-Adresse). Vom LANCOM-Router nicht akzeptierte IKE_SA_INIT-REQUEST's werden mit der oben stehenden Fehlermeldung unverarbeitet verworfen.
Zuletzt geändert von GrandDixence am 01 Okt 2020, 13:31, insgesamt 1-mal geändert.
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: Keine IKEv2-Verbindung zu 1793VA möglich (eingehende IKEv2-Pakete können keinem Peer zugeordnet werden)

Beitrag von backslash »

Hi Agamemnon ,

dein Problem ergibt sich aus:
In der Filiale steht ein anderer Router (nicht von Lancom), der aber IPSEC passieren läßt. In der Filiale soll das VPN von einem Client-Rechner aus aufgebaut werden, mithilfe des in Windows integrierten VPN-IPSec-Clients, über IKEv2 und Maschinen-Zertifikate (das ging im langen Text meiner Frage wohl unter).
und der letzten Zeile aus dem VPN-Status-Trace deines ersten Postings:

Code: Alles auswählen

[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
Wenn die der Filial-Router keinen (dyn)DNS-Namen hat, dann kommt die Verbindung als "unbekannt" rein und du mußt den "DEFAULT" Eintrag unter VPN -> IPEv2/IPSEc -> Verbindungs-Liste wieder aktivieren. Der ist nicht um sonst da drin und er ist auch nicht umsonst in der Defaulteinstellung aktiv. Hättest du ihn nicht deaktiviert, dann hättest du das Problem vermutlich nicht

Gruß
Backslash
Agamemnon
Beiträge: 11
Registriert: 12 Dez 2019, 19:33

Re: Keine IKEv2-Verbindung zu 1793VA möglich (eingehende IKEv2-Pakete können keinem Peer zugeordnet werden)

Beitrag von Agamemnon »

Hallo Backslash,

erst einmal vielen Dank!

BEIDE Router haben einen dyndns-Namen, auch wenn der in der Filiale ein anderes Fabrikat ist. Die beiden Traces im vierten Post dieses Threads zeigen (nach meiner Interpretation), daß das funktioniert. Der erste Trace sagt, daß vpn.filiale.de zu 79.192.36.180 aufgelöst wird, und der zweite Trace zeigt, daß das von dieser Adresse eingehende Paket keiner konfigurierten Verbindung zugeordnet werden kann ...

Viele Grüße,

Agamemnon
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: Keine IKEv2-Verbindung zu 1793VA möglich (eingehende IKEv2-Pakete können keinem Peer zugeordnet werden)

Beitrag von backslash »

Hi Agamemnon,

OK, dann in die nächste Runde
Das gleiche Problem tritt übrigens sogar dann auf, wenn ich in der Verbindung ROTH_CONN als entferntes Gateway direkt die IP-Adresse der Filiale eingebe. Sogar dann kann das eingehende IKEv2-Paket, das ja genau von dieser Adresse aus gesendet worden ist, keiner Verbindung zugeordnet werden.
das deutet dann aber eher darauf hin, daß die VPN-Konfiration nicht korrekt ist und somit gar keine VPN-Regeln angelegt werden. Was sagt denn ein "show vpn" auf dem CLI?
Vielleicht gibt es ja einen Fehler in "PP_ENCRYPTION", "PP_CONNECTION" oder "PP" - was passiert, wenn du die Felder "Encrpytion", "Connection parameters" und "Lifetimes" wieder zurück auf "DEFAULT" stellst?

Gruß
Backsash
Agamemnon
Beiträge: 11
Registriert: 12 Dez 2019, 19:33

Re: Keine IKEv2-Verbindung zu 1793VA möglich (eingehende IKEv2-Pakete können keinem Peer zugeordnet werden)

Beitrag von Agamemnon »

Hallo Backslash,

nochmals danke! Die möglichen komplizierten Gründe, aus denen es nicht funktioniert hat und denen ich nun seit 25 Arbeitsstunden hinterherrenne, waren es nicht.

Ich habe es mittlerweile aber herausgefunden:

Ich hatte noch keine Netzwerkregel angelegt und natürlich in der Verbindung auch nicht zugewiesen. Verflucht sei Lancom! Was zum Geier hat eine Netzwerkregel mit der Zuordnung des ersten IKE-Pakets zu einer Verbindung zu tun? Und dazu noch die hirnrissigen, völlig irreführenden Meldungen im Trace, die rein gar nichts mit dieser Ursache zu haben. Zum K... - Danke für 25 verschwendete Stunden.

Auf jeden Fall kann dieses Problem nun als gelöst betrachtet werden. Eine Verbindung kann ich trotzdem noch nicht aufbauen, auch nicht mit dem LANcom Advanced VPN Client. Dieses neue Problem gehört aber in einen anderen Thread, den ich gleich eröffnen werde.

An Euch beide (Backslash und GrandDixence) nochmals vielen Dank!

Viele Grüße,

Agamemnon
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: Keine IKEv2-Verbindung zu 1793VA möglich (eingehende IKEv2-Pakete können keinem Peer zugeordnet werden)

Beitrag von backslash »

Hi Agamemnon,
Verflucht sei Lancom! Was zum Geier hat eine Netzwerkregel mit der Zuordnung des ersten IKE-Pakets zu einer Verbindung zu tun?
nun die gehört zum Regelsatz ("Phase-2). Ohne ist der Regelsatz nicht vollständig und wird nicht angelegt - schließlich macht es überhaupt keinen Sinn die Phase-1 auszuhandeln, wenn man keine Nutzdaten über die Verbindung senden kann.

Aber wie man mit einem so simplen Fehler 25 Stunden verbringen kann und dann auf Lancom flucht, statt sich das Problem selbst zuzugestehen, kann ich beim besten Willen nicht bachvollziehen - schließlich mußt du dafür entweder die Regelerzeugung explizit von deren default "automatisch" auf "manuell" umgestellt oder aber keine Route zum Zielnetz eingetragen haben. Und gerade Letzteres ist eigentlich das aller Erste, was man macht, wenn man eine Gegenstelle einrichtet. Daher hat da auch niemand nach gefragt.

Beides sind keine Probleme, die man Lancom vorwerfen kann.

Gruß
Backslash
Agamemnon
Beiträge: 11
Registriert: 12 Dez 2019, 19:33

Re: Keine IKEv2-Verbindung zu 1793VA möglich (eingehende IKEv2-Pakete können keinem Peer zugeordnet werden)

Beitrag von Agamemnon »

Hallo backslash,

erst nochmals vielen Dank!
backslash hat geschrieben: 02 Okt 2020, 10:43
Verflucht sei Lancom! Was zum Geier hat eine Netzwerkregel mit der Zuordnung des ersten IKE-Pakets zu einer Verbindung zu tun?
nun die gehört zum Regelsatz ("Phase-2). Ohne ist der Regelsatz nicht vollständig und wird nicht angelegt - schließlich macht es überhaupt keinen Sinn die Phase-1 auszuhandeln, wenn man keine Nutzdaten über die Verbindung senden kann.
Das sehe ich etwas anders. Ich habe beim Einrichten von IPSec-VPNs per IKEv2 (mit anderer Hard- und Software) immer zuerst mal das erste beim Gateway eingehende Paket getracet, mir die Antwort angesehen, und mich so Paket für Paket weitergearbeitet, bis schließlich Phase 2 erreicht wurde; das ist eben meine Vorgehensweise.

Außerdem sind die LANCOM-Router in KMUs recht weit verbreitet und eignen sich somit gut für diverse Tests - zum Beispiel, ob ein erstes von einem Windows-Client hinter einem NAT-Router eingehendes IKEv2-Paket überhaupt einen Abnehmer findet ... für diesen einfaches Test schon Regeln anzulegen, kam mir nicht in den Sinn, weil diese mit der Verarbeitung der ersten Pakete nach aller Logik nichts zu tun haben sollten.
backslash hat geschrieben: 02 Okt 2020, 10:43 Aber wie man mit einem so simplen Fehler 25 Stunden verbringen kann und dann auf Lancom flucht, statt sich das Problem selbst zuzugestehen, kann ich beim besten Willen nicht bachvollziehen - schließlich mußt du dafür entweder die Regelerzeugung explizit von deren default "automatisch" auf "manuell" umgestellt oder aber keine Route zum Zielnetz eingetragen haben. Und gerade Letzteres ist eigentlich das aller Erste, was man macht, wenn man eine Gegenstelle einrichtet. Daher hat da auch niemand nach gefragt.

Beides sind keine Probleme, die man Lancom vorwerfen kann.
Ich empfinde hohen Respekt gegenüber Dir, aber ich bin dennoch anderer Meinung. Wenn (wahlweise) das hunderte Seiten dicke LCOS-Handbuch auch nur mit einer einzigen Silbe darauf hingewiesen hätte, daß ohne Regeleintrag sogar das allererste Client-IKEv2-Paket bereits ins Nirwana läuft, oder die betreffenden Meldungen aus dem Trace in irgendeiner Richtung zielführend gewesen wären, würde ich zumindest darüber nachdenken, mich an der eigenen Nase zu fassen.

Zumindest das kann man LANCOM vorwerfen.

Im Übrigen hatte ich an den Regeln noch nichts verstellt - der Router war neu. Warum das dann trotzdem nicht funktioniert hat, obwohl die Regel automatisch hätte erzeugt werden und die Sache dann flutschen hätte sollen, kann ich nicht mehr nachvollziehen. Ich habe keine Sicherung des Liefer-Zustandes gezogen (warum auch - dafür gibt's den Reset), d.h. ich kann nicht mehr analysieren, was da tatsächlich ursprünglich eingestellt war.

Und eine Software-Architektur, die angelegte Netzwerkregeln benötigt, um bereits das erste eingehende IKEv2-Paket überhaupt einer Verbindung zuordnen zu können, anstatt hierfür den DNS-Namen der Absender-IP oder die Absender-IP selbst zu verwenden, ist absolut überraschend und fragwürdig, um keinen stärkeren Ausdruck zu gebrauchen, jedenfalls für mich. So etwas habe ich auch bei anderen Systemen noch nie gesehen. Auch die freundlichen und kompetenten Helfer hier weisen immer wieder darauf hin, daß für die Zuordnung eigentlich der korrekte Eintrag der Gegenstelle auf beiden Seiten entscheidend ist.

Und auch diese vergurkte Architektur kann man LANCOM vorwerfen. Natürlich hätte ich das Problem früher erkennen können; da dieses Verhalten aber nach meinem Empfinden und meiner Erfahrung im höchsten Maße unlogisch ist, habe ich das eben leider nicht.

Aber jetzt klappt es ja, zumindest mit dem AVC. Ich habe jetzt noch die Aufgabe, das mit dem nativen Windows-Client hinzubekommen ...

Nochmals viele Grüße und vielen Dank,

Agamemnon
GrandDixence
Beiträge: 1054
Registriert: 19 Aug 2014, 22:41

Re: Keine IKEv2-Verbindung zu 1793VA möglich (eingehende IKEv2-Pakete können keinem Peer zugeordnet werden)

Beitrag von GrandDixence »

Gemäss der entsprechenden VPN-Anleitung unter:
fragen-zum-thema-vpn-f14/vpn-via-androi ... tml#p97795
sollte die Regelerzeugung "Manuell" erfolgen. Dies hat seine guten Gründe.
Agamemnon hat geschrieben: 02 Okt 2020, 12:33Ich habe jetzt noch die Aufgabe, das mit dem nativen Windows-Client hinzubekommen ...
Sollte mit der entsprechenden VPN-Anleitung unter:
fragen-zum-thema-vpn-f14/vpn-via-androi ... tml#p97795

und den mehrseitigen Anweisungen unter:
fragen-zum-thema-vpn-f14/windows-10-mit ... 4-s15.html
kein Problem sein.
Agamemnon
Beiträge: 11
Registriert: 12 Dez 2019, 19:33

Re: Keine IKEv2-Verbindung zu 1793VA möglich (eingehende IKEv2-Pakete können keinem Peer zugeordnet werden)

Beitrag von Agamemnon »

Hallo GrandDixence,

nochmals vielen Dank - Deine Anleitungen hatte ich gleich am Anfang studiert, bevor ich überhaupt die ersten Klicks in der Lancom-Oberfläche gemacht habe :-)

Es läuft jetzt ohne Probleme, das VPN baut sich rasend schnell auf und ab, und mit der Stärke der Verschlüsselung des nativen Client bin ich mit einer Ausnahme zufrieden. Diese Ausnahme ist, daß der Client nur MODP-2048 für PFS beherrscht. Das wäre im Moment der einzige Grund für mich, auf den AVC zu wechseln; MODP-2048 sollte eigentlich für neue Setups nicht mehr verwendet werden. Im Moment kann ich aber noch gut damit leben, und ich gehe davon aus, daß Windows mit den nächsten Versionen hier nachbessert. Alles andere ist ohnehin perfekt - durchgängig GCMAES-256.

Aus Privacy- und Performance-Gründen verwende ich Split Tunneling, was der native Windows-Client ebenfalls ohne großes Rumeiern beherrscht. Ein wenig Schwierigkeiten hatte ich damit, zu verhindern, daß alle DNS-Anfragen möglicherweise ins Firmennetz geleitet werden, aber auch das ist mittlerweile gut gelöst, dank der Windows NRPT (die Anfragen für die interne Firmen-Domain firma.local gehen über das VPN an den Lancom, alle anderen Domains werden über die in Windows hinterlegten Standard-Nameserver aufgelöst).

Es verbleiben noch zwei Probleme:

1) Ich verwende IKE-CFG, d.h. der Router teilt dem einwählenden Client die IP-Adresse zu, nebst einiger anderer Informationen. Leider wird dabei auch der Nameserver zugeteilt, was ich nicht möchte; wie gesagt möchte ich die Namensauflösung ausschließlich über NRPT regeln.

Ich habe auf dem Router keine Möglichkeit gefunden, die Zuteilung des Nameservers zu unterdrücken. Es gibt dort in der IKEv2-Konfiguration zwei Felder, in die man Nameserver eintragen kann und die standardmäßig mit 0.0.0.0 vorbelegt sind, was dann offensichtlich dazu führt, daß der Router dem Client seine eigene IP als Nameserver übermittelt.

Diese beiden Felder lassen sich aber leider nicht leeren, sondern nur ändern. Ich habe auch keine Stelle gefunden, an der man festlegen könnte, welche Konfigurations-Teile (IP-Adresse, DNS-Server, etc.) an den Client übermittelt werden sollen und welche nicht. Um zu einer schnellen Lösung zu gelangen, habe ich in beiden Feldern einfach 127.0.0.1 eingetragen, was soweit auch funktioniert, aber die Namensauflösung im Client verlangsamen kann - von dieser Lösung möchte ich wieder weg.

Wahrscheinlich habe ich wieder etwas übersehen. Gibt es eine Möglichkeit, die Übermittlung des Nameservers an den Client bei IKE-CFG zu unterdrücken und wirklich nur die IP-Adresse mitzuteilen?

Eventuell sollte ich für diese Frage einen neuen Thread eröffnen - sie ist vom ursprünglichen Thema doch ein Stück entfernt.

2) Was mir auch noch nicht schmeckt, ist das Thema Multicast (wofür der Router aber nichts kann). Ich habe gesehen, daß nach VPN-Einwahl auf dem VPN-Interface eine Route für Multicast gesetzt ist; das möchte ich nicht. Ich muß zusehen, wie ich das auf Windows-Ebene verhindern kann.

Vor allem auf die Antwort auf Frage 1) wäre ich neugierig ... :-)

Nochmals vielen Dank und viele Grüße,

Agamemnon
Antworten