Was bedeutet Fehlermeldung "no exchange available ,failure"?

[Sebulba]

Hallo,

ich möchte gerne eine VPN-Verbindung von StrongSwan (Linux, Debian wheezy) zu einem Lancom 1781VA herstellen, und zwar unter Verwendung von Zertifikaten und IKEv2. Dies ist mir nun im Laufe von 16 Arbeitsstunden nicht gelungen, so daß ich hier auf Hilfe hoffe. Das Problem stellt sich wie folgt dar:

Der Trace zeigt, daß der Lancom das erste IKEv2-Paket empfängt, aber dann bereits an dieser Stelle aussteigt; offenbar gefällt ihm die Syntax des Paketes nicht. Der relevante Ausschnitt aus dem Trace befindet sich am Ende dieser Nachricht.

Weitere Informationen: Die CA ist korrekt eingerichtet, die Zertifikate sind korrekt in den Lancom und in StrongSwan geladen. Der Aufbau der VPN-Verbindung mit IKEv1 funktioniert einwandfrei. Ich möchte die Verbindung jedoch mit IKEv2 aufbauen.

Es wäre schön, wenn ein Experte den folgenden Log betrachten und mir mitteilen könnte, was genau an dem Paket nicht paßt und was die Meldung "no exchange available, failure" bedeutet.

Viele Grüße und vielen Dank,

Sebulba

Code: Alles auswählen

[VPN-IKE] 2016/07/17 12:21:42,287  Devicetime: 2016/07/17 12:21:56,347
Received packet:
IKE 2.0 Header:
Source/Port         : 79.239.246.194:500
Destination/Port    : 79.192.41.137:500
VLAN-ID             : 0
HW switch port      : 0
Routing-tag         : 0
Com-channel         : 1
Loopback            : NO
| Initiator cookie  : EA 72 ED 18 62 C2 F1 42
| Responder cookie  : 00 00 00 00 00 00 00 00
| Next Payload      : SA
| Version           : 2.0
| Exchange type     : IKE_SA_INIT
| Flags             : 0x08   Initiator
| Msg-ID            : 0
| Length            : 688 Bytes
SA Payload
| Next Payload      : KE
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 48 Bytes
| PROPOSAL Payload
| | Next Payload    : NONE
| | Reserved        : 0x00
| | Length          : 44 Bytes
| | Proposal number : 1
| | Protocol ID     : IPSEC_IKE
| | SPI size        : 0
| | #Transforms     : 4
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 12 Bytes
| | | Transform Type: ENCR
| | | Reserved2     : 0x00
| | | Transform ID  : AES_CBC
| | | Attribute 0
| | | | Type        : Basic, KEYLENGTH
| | | | Value       : 256
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: INTEG
| | | Reserved2     : 0x00
| | | Transform ID  : SHA-512
| | | Attributes    : NONE
| | TRANSFORM Payload
| | | Next Payload  : TRANSFORM
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: PRF
| | | Reserved2     : 0x00
| | | Transform ID  : PRF-HMAC-SHA-512
| | | Attributes    : NONE
| | TRANSFORM Payload
| | | Next Payload  : NONE
| | | Reserved      : 0x00
| | | Length        : 8 Bytes
| | | Transform Type: DH
| | | Reserved2     : 0x00
| | | Transform ID  : 16
| | | Attributes    : NONE
KE Payload
| Next Payload      : NONCE
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 520 Bytes
| DH Group          : 16
| Reserved2         : 0x0000
| DH-Key(4096 bits) : 71 8C DF 36 86 AC F0 73 C2 BC 1B 26 47 F5 AC CD
|                     99 CB A6 46 94 C4 9A 77 5B 55 CD 5E B3 5C 8D E6
|                     BA 46 21 20 91 82 74 90 7E B2 B3 0D 1C EF 14 05
|                     63 0C C3 E7 2C 43 92 07 23 41 AB 6F C5 9E 6E 15
|                     AA B7 41 1B 98 33 D0 0A 01 74 79 4A 69 45 7D 20
|                     31 09 E2 D6 49 96 BF FA 84 85 04 12 13 EB 7D E6
|                     41 86 70 C6 36 42 67 E0 96 3F 5A 52 C1 9E A5 7F
|                     69 40 F2 72 C6 F7 2E AE 6A CA 5B C5 98 06 C6 AC
|                     D3 C8 61 3D F8 1E F2 0E 8B 05 58 05 23 8A 29 6E
|                     CE DB 3D E0 DD 9E 63 D8 94 65 0C F7 E8 C4 18 46
|                     CB 9F F6 96 BC 52 E3 28 8A 6B 81 DF DA 38 2F 24
|                     4E 89 36 B9 53 22 D7 73 0D 30 BA 5B DE 35 2A 57
|                     57 24 65 22 39 3B 15 15 B9 3F D7 7E BA D3 4F D1
|                     F1 F2 B4 8F 4F D2 92 87 2B 51 3D DC 20 25 EA 51
|                     F3 35 4A D9 BD B6 86 50 34 2B C7 1D 8E 3E 2C AE
|                     27 20 3E 54 0E 54 84 98 92 AD 3B 71 DF 21 EA D9
|                     41 5C 4D EC 47 E4 9C BD EA 9D 3C 7C 6E F6 D6 C0
|                     5F 41 7D 8C CA 04 97 BD F4 F6 77 86 6D 52 B4 EB
|                     90 9F A6 79 49 62 CF 29 7E BD 32 DA D9 29 AB 1E
|                     75 F3 F6 80 10 3F D8 30 5C 2D CC E0 BD B4 FA 41
|                     6E B3 58 B1 49 06 57 3F 66 13 AF 1E 75 17 5A 7D
|                     65 75 34 89 7A FF 66 CA 49 F3 15 D1 0F E1 A0 8F
|                     37 2A B3 A4 00 C4 74 B8 84 C2 2D 79 7A E1 E8 FB
|                     AC 2B BC EE C0 2C 4D A3 7A 05 B7 E8 C7 6D CD DA
|                     C9 D0 C7 EA 9B 93 FE BB E8 CB 2F 6C 66 76 E5 B7
|                     63 51 2E 7B D7 00 DF 97 48 CF 3D 19 B7 79 7F 32
|                     3D 93 16 BD 88 0B DC CA 09 3A D8 9D 98 E9 7A A2
|                     0D D9 B8 AE 35 46 9E F9 1F 38 38 7B 3B BC 8D BA
|                     08 91 40 4A 85 C4 D7 43 6F F4 16 51 AA B8 09 8C
|                     9D 4E 05 0E 45 D3 12 5C 23 AE AB 7B 2B B8 7D DA
|                     68 06 6C 4F 3D 0A 32 55 28 E7 C0 17 CE F1 35 58
|                     37 77 0C FA 01 22 FE FA 68 A9 73 70 9F 9A 33 AF
NONCE Payload
| Next Payload      : NOTIFY
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 36 Bytes
| Nonce(256 bits)   : 29 77 2B 7D 6C 94 7E 51 D1 BA 31 BF 1F C1 8C 6C
|                     40 78 DF 94 5B E4 DD EA 24 4D 8F 8C 00 08 2B 4F
NOTIFY Payload
| Next Payload      : NOTIFY
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 28 Bytes
| Protocol ID       : <Unknown 0>
| SPI size          : 0
| Message type      : STATUS_NAT_DETECTION_SOURCE_IP
| Notif. data       : FB 59 62 75 F3 D3 14 3F 3D A7 25 26 3F AC E6 9B
|                     91 71 DA B7
NOTIFY Payload
| Next Payload      : NONE
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 28 Bytes
| Protocol ID       : <Unknown 0>
| SPI size          : 0
| Message type      : STATUS_NAT_DETECTION_DESTINATION_IP
| Notif. data       : 61 C6 11 AE AF 9D 48 28 F8 26 3C A3 1D 45 84 6A
|                     E5 27 67 00

[VPN-Status] 2016/07/17 12:21:42,287  Devicetime: 2016/07/17 12:21:56,348
IKE info: message_v2_validate_sa: no exchange available, failure

[VPN-Status] 2016/07/17 12:21:42,287  Devicetime: 2016/07/17 12:21:56,348
IKE info: ikev2: dropped message from 79.239.246.194 port 500 due to notification type INVALID_SYNTAX

[GrandDixence]

Nach dem IKE_SA_INIT-Telegramm sollte der LANCOM-Router mit dem "Response IKE_SA_INIT"-Telegramm für die Aushandlung der Verschlüsselung und Schlüssel (IKE) antworten. Strongswan bietet im IKE_SA_INIT-Telegramm dem LANCOM-Router:

a) Die Verschlüsselungsmethode AES_CBC_256_SHA-512 und
b) für den Austausch (Exchange) des Verschlüsselungs-Schlüssel das Verfahren DH mit Group 16 (4096 Bit) und
c) für die Erzeugung der Schlüsseln das Pseudo-Zufallsverfahren: PRF-HMAC-SHA-512 an,

was der LANCOM-Router nicht akzeptieren darf (no exchange available, failure), weil er so konfiguriert wurde.

Grund: Konfigurationsfehler => Folgende LCOS-Einstellungen kontrollieren bzw. korrigieren:

Setup > VPN > IKEv2 > Verschlüsselung
Setup > VPN > IKEv2 > Digital-Signatur-Profile

Siehe auch BSI TR-02102-3:
https://www.bsi.bund.de/DE/Publikatione ... x_htm.html

[MariusP]

Hi,
Es kann auch sein, das die IP Addresse nicht stimmt oder dass er bei Einwahlclients mit zufälliger IP keinen Peer mit DEFAULT Eintrag findet.

Welche Version verwendest du?
In aktuellen Versionen sollten mehr Ausgaben dazu auftauchen, daher bitte mal mit einer aktuellen testen.
Gruß

[Sebulba]

Hallo,

erst einmal vielen Dank für die Rückmeldungen. Die (mittlerweile) 24 Stunden Arbeit habe ich dem Lancom-Support zu verdanken.

Der Fehler lag schlicht und ergreifend darin, daß bei dem neuen Router, den wir gekauft hatten, bereits im Neuzustand eine VPN-Verbindung angelegt (und als aktiv geschaltet!) war. Nach Deaktivierung derselben hat alles funktioniert wie gewünscht (nach einigen weiteren Feineinstellungen). Es lag also nicht an irgendwelchen Verschlüsselungs-Optionen, sondern an der im Werkszustand aktiven VPN-Verbindung! Diese war offenbar so konfiguriert, daß sie sich als erstes alle eingehenden IKEv2-Pakete gekrallt hat, ohne daß die zweite, von uns angelegte Verbindung überhaupt etwas davon gesehen hat.

Warum ist nun Lancom an den 24 Stunden schuld? Ganz einfach: Ich hatte mit dem Lancom-Support in einer anderen Sache telefoniert und habe dabei die ausdrückliche Anweisung erhalten, *AUF KEINEN FALL* *IRGENDEINE* das VPN betreffende Default-Einstellung zu verändern - vielen Dank für die kompetente Auskunft, aufgrund derer Arbeitszeit im Wert zwischen 1000 und 2000 EUR verschwendet worden ist.

Die besagte VPN-Verbindung war als IKEv2-Verbindung angelegt; es war *KEINE* IKEv1-Verbindung angelegt. Deshalb hatte IKEv1 auch quasi auf Anhieb funktioniert.

Viele Grüße,

Sebulba

P.S. Die im Paket sichtbaren Optionen passen so und werden von LCOS 9.20 auch unterstützt (SHA512, AES256, MODP4096 etc.). Ich möchte schließlich so sicher wie möglich fahren, und die Unterstützung dieser Verschlüsselungs- und Hashing-Methoden in LCOS 9.20 war der Grund für den Kauf. Schade, das AES-GCM (noch) nicht implementiert ist ... aber vorerst paßt's.

[MariusP]

Hi,
Bedenke, wie ich erwähnt hatte gibt es einen Defaulteintrag, welcher für Einwahlclients zuständig ist.
Dieser ist dann interessant, wenn du keine statische Internet-Adresse hast. Denn das LCOS musst die Algorithmen in dem Initiatorpacket auf irgendwas matchen für den weiteren Verlauf der Verhandlung.
Wenn du also keinen Eintrag hast, dessen IP-Adresse genau mit der matched, die im eingehenden Packet steht, wird dieser richtiger Weise auf den Defaulteintrag gematched. Sonst hat das VPN garkeine Chance das eingehende Packet zu matchen.

Da deine Konfig uns nicht gezeigt hast, können wir nur mutmaßen.

Du kannst die Einträge löschen, da du sie ja mit einem "default" wieder erzeugen kannst. Denke, das ohne die Defaulteinträge manche Szenarien nicht umsetzbar sind. Und diese sofern, der Rest richtig konfiguriert ist, auch kein Problem darstellen.

Gruß

P.S.:

AES-GCM (noch) nicht implementiert ist ... aber vorerst paßt's.

I/We will try my/our very best.

[Sebulba]

Hallo,

vielen Dank für die Antwort.

Da kamen dann mehrere Dinge zusammen. Vielleicht könnte man irgendwo erklären, was die Fehlermeldung bedeutet? Das hätte vermutlich einige Stunden erspart.

Zum Matching: Wenn man mit Zertifikaten arbeitet, möchte man ja normalerweise aufgrund des DN (ASN.1) matchen. Wie könnte man nun das frühzeitige korrekte Matching (also anhand IP oder FQDN) mit dem DN-Matching vereinen? Wie reagiert LCOS 9.20, wenn ich zwar mit Zertifikaten arbeite, als ID jedoch einen FQDN verwende?

Meine VPN-Zertifikate weisen einen DN folgender Form auf: /CN=lancom.public.domain bzw. /CN=other-end.public.domain

Ich war nun davon ausgegangen, daß der Lancom sich beim Starten und dann in regelmäßigen Abständen die IP-Adressen für alle in den hinterlegten Zertifikaten vorhandenen CNs sucht (sofern die CNs eben ein FQDN sind) und dann eingehende Pakete richtig zuordnen kann. Gibt es keine solche Möglichkeit? Würde es mit Zertifikaten funktionieren, die einen DN folgender Form aufweisen: lancom.public.domain bzw. other-end.public.domain (also ohne /CN=)?

Alle beteiligten IP-Adressen sind übrigens "pseudo-statisch", d.h. Telekom-All-IP (Zwangstrennung alle 180 Tage). Ich könnte sehr gut damit leben, daß alle 180 Tage ein VPN unterbrochen wird, aber ich möchte natürlich nicht alle 180 Tage die Router-Konfiguration ändern oder neue Zertifikate verwenden, zumal während des Sommers (Gewitter!) dies dann wöchentlich nötig wäre.

Viele Grüße und vielen Dank,

Sebulba

[MariusP]

Hi,

Da kamen dann mehrere Dinge zusammen. Vielleicht könnte man irgendwo erklären, was die Fehlermeldung bedeutet? Das hätte vermutlich einige Stunden erspart.

Wie ich erwähnte, wurde hierran schon gearbeitet:

In aktuellen Versionen sollten mehr Ausgaben dazu auftauchen, daher bitte mal mit einer aktuellen testen.

Ich kenne mich selber leider nicht so gut mit den Zertifikaten aus um dir dort ohne viel Zeitaufwand eine ausreichend zufriedenstellende Antwort geben zu können.
Gruß

[Sebulba]

Hallo,

nochmals danke für die Antwort.

Was die Version anbelangt: Auf dem Gerät ist ja schon die 9.20. Eine Beta (sofern es eine gibt - ich habe es nicht überprüft) möchte ich nicht aufspielen ...

Aber ich bin jetzt erst einmal zufrieden. Auf etwaige Probleme mit dem Matching werde ich dann stoßen, wenn weitere VPN-Verbindungen angelegt werden. Wenn ich das dann nicht lösen kann, melde ich mich nochmals.

Viele Grüße und vielen Dank,

Sebulba