Hallo!
Ich will Road-Warrior mit LANCOM Advanced VPN Client und anderen Clients mit einem LANCOM Router (FW 7.58 ) verbinden.
Dabei werden IPCec, NAT-T und Main Mode/Zertifikate benutzt.
Ich habe schon sehr lange nach der Ursache gesucht (viele Stunden), nebenbei gab es noch einen Bug in der Firmware.
Die VPN-Verbindung kann nicht vollständig aufgebaut werden, schon in IKE-Phase-2 gibt's ein Problem.
Bei der IKE-Phase-2 kommt es im LANCOM-Router-Trace zu folgender Meldung:
IKE info: Phase-2 failed for peer def-main-peer: no rule matches the phase-2 ids 192.168.1.101 <-> 192.168.1.0/255.255.255.0
Ich bin sicher, daß die grundsätzliche Konfiguration und das theoretische Modell dahinter richtig sind, und will daher nicht mit ellenlangen Konfig-Details langweilen. Nur soviel: Kein IKE-Conf.
Kann mir jemand sagen, welche "rule" genau gemeint ist, damit ich danach suchen kann?
Es müßte sich ja eigentlich um die in Firewall/QoS eingetragene Regel ("Diese Regel wird zur Erzeugung von VPN-Regeln herangezogen") handeln, sowie um den Eintrag in der IP-Router / Routing-Tabelle, denn das sind die einzigen Stellen, wo ich die entsprechenden IP-Adressen bzw. Netze, welche mit dem Assistenten erzeugt wurden, wiederfinde.
Was sind genau die "VPN-Regeln", die da Firewall/QoS-Regeln "heranziehen"? Dynamisch bei VPN-Verbindungsaufbeu erzeugte? Oder kann man die irgendwo sehen?
Vermutlich sind's die, welche man mit "show vpn rule" sehen kann. (Sie stimmen übrigens überein, funktioniert trotzdem nicht:
Connection #1 192.168.1.0/255.255.255.0:0 <-> 192.168.1.101/255.255.255.255.0 any)
Nebenbei:
Mit sicherheitsarmes IPSec im Aggressive Mode mit PSK und IKE-Conf konnte testhalber erfolgreich verbunden werden.
Danke,
telchef
no rule matches the phase-2 ids 192.168.1.101 <-> 192
Moderator: Lancom-Systems Moderatoren
Man, was für eine irreführende Meldung, diese "no rule matches the phase-2..."!
Es scheint an dem Subject der Zertifikate zu liegen, daß der LANCOM keine passende "rule" findet.
Seltsamerweise zeigt der LANCOM-Trace den ASN.1 Distinguished Name auch in umgekehrter Reihenfolge und ohne Leerzeichen hinter den Kommata an.
Was genau der LANCOM nun an meinen Zertifikaten bzw. der Zeichenketten für "Lokale Identität" und "Entfernte Identität" nicht erkennt, habe ich noch nicht heruasgefunden. (Sonderzeichen sind im Subject nicht enthalten.)
(Mit anderen VPN-Gateways arbeiten die selben Zertifikate einwandfrei!)
Vielleicht kann mir jemand auf die Sprünge helfen.
telchef
Es scheint an dem Subject der Zertifikate zu liegen, daß der LANCOM keine passende "rule" findet.
Seltsamerweise zeigt der LANCOM-Trace den ASN.1 Distinguished Name auch in umgekehrter Reihenfolge und ohne Leerzeichen hinter den Kommata an.
Was genau der LANCOM nun an meinen Zertifikaten bzw. der Zeichenketten für "Lokale Identität" und "Entfernte Identität" nicht erkennt, habe ich noch nicht heruasgefunden. (Sonderzeichen sind im Subject nicht enthalten.)
(Mit anderen VPN-Gateways arbeiten die selben Zertifikate einwandfrei!)
Vielleicht kann mir jemand auf die Sprünge helfen.
telchef
Krass: Problem gelöst!
Die Subjects (die DNs) der Zertifikate müssen im LANCOM bei "Lokale Identität" und "Entfernte Identität" genau in umgekehrter Reihenfolge eingegeben werden, wie sie in openssl, in FreeS/WAN oder in Openswan sowie in deren Logs zu sehen sind.
Das hatte ich bei diesem konkreten Fall vergleichsweise schnell entdeckt.
Selbstverständlich war die umgekehrte Eingabe der DN-Elemente in der LANCOM-Konfiguration einer meiner ersten Lösungsversuche. Unglücklicherweise muß ich mich bei meinen ellenlangen DNs wohl vertippt haben, so brachte mich das nicht zum Erfolg, und eine stundenlange Fehlersuche begann...
Am Ende habe ich es einfach _nochmal_ mit umgekehrten DNs versucht, und da klappte der Tunnelaufbau prompt.
Die Fehlermeldung des Threads lag also ausschließlich an "falschen" DNs in den Identität-Eingabefeldern.
Von den LANCOM-Entwicklern würde ich mir verständlichere und eindeutigere Fehlermeldungen wünschen. (Aber die Komplexität von IPSec läßt in nahezu allen Implementierungen die Meldungen einen großen Schwachpunkt sein.)
Ich hoffe, dieses Selbstgespräch ist auch nochmal für andere nützlich!
Würde mich über einen Kommentar freuen.
Grüße,
telchef
Die Subjects (die DNs) der Zertifikate müssen im LANCOM bei "Lokale Identität" und "Entfernte Identität" genau in umgekehrter Reihenfolge eingegeben werden, wie sie in openssl, in FreeS/WAN oder in Openswan sowie in deren Logs zu sehen sind.
Das hatte ich bei diesem konkreten Fall vergleichsweise schnell entdeckt.
Selbstverständlich war die umgekehrte Eingabe der DN-Elemente in der LANCOM-Konfiguration einer meiner ersten Lösungsversuche. Unglücklicherweise muß ich mich bei meinen ellenlangen DNs wohl vertippt haben, so brachte mich das nicht zum Erfolg, und eine stundenlange Fehlersuche begann...
Am Ende habe ich es einfach _nochmal_ mit umgekehrten DNs versucht, und da klappte der Tunnelaufbau prompt.
Die Fehlermeldung des Threads lag also ausschließlich an "falschen" DNs in den Identität-Eingabefeldern.
Von den LANCOM-Entwicklern würde ich mir verständlichere und eindeutigere Fehlermeldungen wünschen. (Aber die Komplexität von IPSec läßt in nahezu allen Implementierungen die Meldungen einen großen Schwachpunkt sein.)
Ich hoffe, dieses Selbstgespräch ist auch nochmal für andere nützlich!
Würde mich über einen Kommentar freuen.
Grüße,
telchef