Nach Update auf 5.3.10: VPN Verbindung mit Shrew funktioniert nicht mehr

[Piechowski]

Hallo,

nach dem gestrigen Update auf die Version 5.3.10 können sich unsere Shrew Clients nicht mehr verbinden.

Hier ein Auszug aus dem log:

Aug 2 11:17:37 mail pluto[2618]: packet from 84.151.219.147:973: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
Aug 2 11:17:37 mail pluto[2618]: packet from 84.151.219.147:973: ignoring Vendor ID payload [16f6ca16e4a4066d83821a0f0aeaa862]
Aug 2 11:17:37 mail pluto[2618]: packet from 84.151.219.147:973: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
Aug 2 11:17:37 mail pluto[2618]: packet from 84.151.219.147:973: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
Aug 2 11:17:37 mail pluto[2618]: packet from 84.151.219.147:973: received Vendor ID payload [RFC 3947]
Aug 2 11:17:37 mail pluto[2618]: packet from 84.151.219.147:973: ignoring Vendor ID payload [FRAGMENTATION 80000000]
Aug 2 11:17:37 mail pluto[2618]: packet from 84.151.219.147:973: received Vendor ID payload [Dead Peer Detection]
Aug 2 11:17:37 mail pluto[2618]: packet from 84.151.219.147:973: ignoring Vendor ID payload [f14b94b7bff1fef02773b8c49feded26]
Aug 2 11:17:37 mail pluto[2618]: packet from 84.151.219.147:973: ignoring Vendor ID payload [166f932d55eb64d8e4df4fd37e2313f0d0fd8451]
Aug 2 11:17:37 mail pluto[2618]: packet from 84.151.219.147:973: ignoring Vendor ID payload [8404adf9cda05760b2ca292e4bff537b]
Aug 2 11:17:37 mail pluto[2618]: packet from 84.151.219.147:973: ignoring Vendor ID payload [Cisco-Unity]
Aug 2 11:17:37 mail pluto[2618]: "C4"[4] 84.151.219.147:973 #74: responding to Main Mode from unknown peer 84.151.219.147:973
Aug 2 11:17:37 mail pluto[2618]: "C4"[4] 84.151.219.147:973 #74: Oakley Transform [AES_CBC (256), HMAC_MD5, MODP_3072] refused due to strict flag
Aug 2 11:17:37 mail pluto[2618]: "C4"[4] 84.151.219.147:973 #74: Oakley Transform [AES_CBC (256), HMAC_MD5, MODP_2048] refused due to strict flag
Aug 2 11:17:37 mail pluto[2618]: "C4"[4] 84.151.219.147:973 #74: Oakley Transform [AES_CBC (256), HMAC_MD5, MODP_1536] refused due to strict flag
Aug 2 11:17:37 mail pluto[2618]: "C4"[4] 84.151.219.147:973 #74: Oakley Transform [AES_CBC (256), HMAC_MD5, MODP_1024] refused due to strict flag
Aug 2 11:17:37 mail pluto[2618]: "C4"[4] 84.151.219.147:973 #74: MODP_768 is not supported. Attribute OAKLEY_GROUP_DESCRIPTION
Aug 2 11:17:37 mail pluto[2618]: "C4"[4] 84.151.219.147:973 #74: Oakley Transform [AES_CBC (256), HMAC_SHA1, MODP_3072] refused due to strict flag
Aug 2 11:17:37 mail pluto[2618]: "C4"[4] 84.151.219.147:973 #74: Oakley Transform [AES_CBC (256), HMAC_SHA1, MODP_2048] refused due to strict flag
Aug 2 11:17:37 mail pluto[2618]: "C4"[4] 84.151.219.147:973 #74: Oakley Transform [AES_CBC (256), HMAC_SHA1, MODP_1536] refused due to strict flag
Aug 2 11:17:37 mail pluto[2618]: "C4"[4] 84.151.219.147:973 #74: Oakley Transform [AES_CBC (256), HMAC_SHA1, MODP_1024] refused due to strict flag
Aug 2 11:17:37 mail pluto[2618]: "C4"[4] 84.151.219.147:973 #74: MODP_768 is not supported. Attribute OAKLEY_GROUP_DESCRIPTION
Aug 2 11:17:37 mail pluto[2618]: "C4"[4] 84.151.219.147:973 #74: Oakley Transform [AES_CBC (192), HMAC_MD5, MODP_3072] refused due to strict flag
Aug 2 11:17:37 mail pluto[2618]: "C4"[4] 84.151.219.147:973 #74: Oakley Transform [AES_CBC (192), HMAC_MD5, MODP_2048] refused due to strict flag
Aug 2 11:17:37 mail pluto[2618]: "C4"[4] 84.151.219.147:973 #74: Oakley Transform [AES_CBC (192), HMAC_MD5, MODP_1536] refused due to strict flag
Aug 2 11:17:37 mail pluto[2618]: "C4"[4] 84.151.219.147:973 #74: Oakley Transform [AES_CBC (192), HMAC_MD5, MODP_1024] refused due to strict flag
Aug 2 11:17:37 mail pluto[2618]: "C4"[4] 84.151.219.147:973 #74: MODP_768 is not supported. Attribute OAKLEY_GROUP_DESCRIPTION
Aug 2 11:17:37 mail pluto[2618]: "C4"[4] 84.151.219.147:973 #74: Oakley Transform [AES_CBC (192), HMAC_SHA1, MODP_3072] refused due to strict flag
Aug 2 11:17:37 mail pluto[2618]: "C4"[4] 84.151.219.147:973 #74: Oakley Transform [AES_CBC (192), HMAC_SHA1, MODP_2048] refused due to strict flag
Aug 2 11:17:37 mail pluto[2618]: "C4"[4] 84.151.219.147:973 #74: Oakley Transform [AES_CBC (192), HMAC_SHA1, MODP_1536] refused due to strict flag
Aug 2 11:17:37 mail pluto[2618]: "C4"[4] 84.151.219.147:973 #74: Oakley Transform [AES_CBC (192), HMAC_SHA1, MODP_1024] refused due to strict flag
Aug 2 11:17:37 mail pluto[2618]: "C4"[4] 84.151.219.147:973 #74: MODP_768 is not supported. Attribute OAKLEY_GROUP_DESCRIPTION
Aug 2 11:17:37 mail pluto[2618]: "C4"[4] 84.151.219.147:973 #74: Oakley Transform [AES_CBC (128), HMAC_MD5, MODP_3072] refused due to strict flag
Aug 2 11:17:37 mail pluto[2618]: "C4"[4] 84.151.219.147:973 #74: Oakley Transform [AES_CBC (128), HMAC_MD5, MODP_2048] refused due to strict flag
Aug 2 11:17:37 mail pluto[2618]: "C4"[4] 84.151.219.147:973 #74: Oakley Transform [AES_CBC (128), HMAC_MD5, MODP_1536] refused due to strict flag
Aug 2 11:17:37 mail pluto[2618]: "C4"[4] 84.151.219.147:973 #74: Oakley Transform [AES_CBC (128), HMAC_MD5, MODP_1024] refused due to strict flag
Aug 2 11:17:37 mail pluto[2618]: "C4"[4] 84.151.219.147:973 #74: MODP_768 is not supported. Attribute OAKLEY_GROUP_DESCRIPTION
Aug 2 11:17:37 mail pluto[2618]: "C4"[4] 84.151.219.147:973 #74: Oakley Transform [AES_CBC (128), HMAC_SHA1, MODP_3072] refused due to strict flag
Aug 2 11:17:37 mail pluto[2618]: "C4"[4] 84.151.219.147:973 #74: Oakley Transform [AES_CBC (128), HMAC_SHA1, MODP_2048] refused due to strict flag
Aug 2 11:18:42 mail pluto[2618]: "C4"[4] 84.151.219.147:973 #73: max number of retransmissions (2) reached STATE_MAIN_R1
Aug 2 11:18:47 mail pluto[2618]: "C4"[4] 84.151.219.147:973 #74: max number of retransmissions (2) reached STATE_MAIN_R1
Aug 2 11:18:47 mail pluto[2618]: "C4"[4] 84.151.219.147:973: deleting connection "C4" instance with peer 84.151.219.147 {isakmp=#0/ipsec=#0}


Client-Einstellungen erfolgten gemäß Handbuch und bis zum Update funktionierte alles einwandfrei.

[Thomas Jarosch]

Hallo Herr Piechowski,

bitte probieren Sie das VPN-Verschlüsselungsprofil "Intranator 5.3.1 und vorherige" für diese VPN-Verbindungen.

Welche Version des Shrew Clients kommt zum Einsatz?

Herzliche Grüße,
Thomas Jarosch

[Piechowski]

Hallo Herr Jarosch,

bitte probieren Sie das VPN-Verschlüsselungsprofil "Intranator 5.3.1 und vorherige" für diese VPN-Verbindungen.

Haben wir bereits ohne Erfolg versucht.

Welche Version des Shrew Clients kommt zum Einsatz?

Die neueste.

[Thomas Jarosch]

Hallo Herr Piechowski,

Haben wir bereits ohne Erfolg versucht.

In Version 5.3.10 wurde die Reihenfolge der angebotenen Verschlüsselungsmethoden korrigiert, da sie genau spiegelverkehrt war. Das Profil "Intranator 5.3.1 und vorherige" enthält die Verschlüsselungsmethoden in der Reihenfolge von Version 5.3.9.

Hintergrund in ein Problem in älteren Versionen des VPN-Systems, das mit AES-256 nicht zurechtkommt.

Die neueste.

Sprich Sie verwenden Version 2.1.7 oder 2.2.0-beta1?

Was Sie probieren können: Stellen Sie im Shrew-Client das Verschlüsselungsverfahren
unter "Phase1" von "auto" auf z.B. AES-128 / SHA1 / "MODP1536" oder "group 5".
Die Einstellungen unter "Phase2" analog dazu.

Herzliche Grüße,
Thomas Jarosch

[Piechowski]

Wir verwenden die Version 2.1.7.

Ich habe Kombinationen verschiedener Cipher und Hashverfahren durchprobiert. Sie wurden alle abgewiesen: "refused due to strict flag"

[Thomas Jarosch]

Ich habe Kombinationen verschiedener Cipher und Hashverfahren durchprobiert. Sie wurden alle abgewiesen: "refused due to strict flag"

Ok, ich würde vorschlagen, daß wir uns das per Fernwartung ansehen. Bitte legen Sie hierfür ein Support-Ticket an:
http://www.intra2net.com/de/support/anfrage.php

Herzliche Grüße,
Thomas Jarosch

[Gerd von Egidy]

Hallo,

ein kurzer Zwischenbericht zu diesem Problem:

Wir konnten nun herausfinden woher das Problem kommt.

In der Konfigurationsnachricht vom Intranator an den Client wird auch die Version des Intranators als Zeichenkette mitgesendet. Durch den Sprung von Version 5.3.9 auf 5.3.10 ist diese Zeichenkette um ein Byte länger geworden. Abhängig von der Länge der auf dem Intranator eingestellten lokalen Domain (die wird auch in der Konfigurationsnachricht übermittelt) kann es jetzt vorkommen, daß die Nachricht im Client nicht mehr richtig decodiert werden kann.

Da der Fehler abhängig von der Länge der Domain ist, ist das Problem bei unseren Tests vor dem Release nicht aufgefallen.

Wir sind nun dabei genau herauszufinden bei welchen Zeichenlängen dieser Fehler im Client auftritt. Gleichzeitig kontaktieren wir den Autor des Clients.

Entweder werden wir in den nächsten Tagen ein Update für den Intranator herausbringen, welches die problematischen Zeichenlängen vermeidet oder es wird eine neue Version des Shrewsoft Clients geben, welche diesen Fehler nicht mehr enthält.

Herzliche Grüße,

v. Egidy

[GrooveAttack]

Hallo Herr v. Egidy,

hätte ich doch einfach mal *vor* dem Update ins Forum geschaut - jetzt ist das Update drauf und mir steht ein lustiger Wochenstart bevor. Offenbar sind auch DrayTek Router von dem Problem betroffen. Mit einer Lösung "im Laufe der Woche" werde ich die 10 Außendienstler (Shrew Client) und 3 HomeOffices (DrayTek) nicht abspeisen können - gibt es nicht ggf. die Möglichkeit, die vom Intranator übertragene Versionsnummer vorübergehend auf z.B. 5.4.0 zu ändern?

Viele Grüße,

Sebastian Wendeler

[Thomas Jarosch]

Hallo Herr Wendeler,

hätte ich doch einfach mal *vor* dem Update ins Forum geschaut - jetzt ist das Update drauf und mir steht ein lustiger Wochenstart bevor.

Per Zufall habe ich gerade mit "Opera Mobile" auf dem Smartphone gespielt und wollte testen, wie die forum.intra2net.com Seite dargestellt wird...

Die Versionsnummer steckt in einer Datenbank und lässt sich von Hand umstellen. Das geht so:
- Als root per ssh auf dem Intranator einloggen
- Folgendes Kommando ausführen

echo "update attributes set value=X'496E7472616E61746F722076352E332E39' where type=7;" |sqlite3 /etc/ipsec.d/ipsec.db

Dann bekommen die Clients wieder die alte Versionsnummer 5.3.9 übermittelt.

Hinweis: Die Datenbank wird bei Änderungen an VPN-Verbindungen oder Netzwerkkarten/Routings neu geschrieben.

Herzliche Grüße,
Thomas Jarosch

[GrooveAttack]

Hallo Herr Jarosch,

vielen Dank für den (sogar sonntäglichen) Support. Bei uns scheint das Problem dann doch nicht zu existieren -
die Software-Clients laufen problemlos auch mit dem aktuellen Verschlüsselungsprofil, die Verbindungen der Draytek Router müssen
zwar auf "5.3.1 und vorherige" umgestellt werden, laufen dann aber auch (gestern konnte ich die Geräte nur deshalb nicht erreichen,
weil die Kollegen doch tatsächlich Strom sparen und die Kisten vom Netz nehmen).

Viele Grüße,

Sebastian Wendeler

[Gerd von Egidy]

Hallo,

wir haben das Problem mit dem Shrew-Client und der 5.3.10 jetzt vollständig verstanden und gelöst:

Bei bestimmten Paketlängen müssen die IKE-Pakete für den VPN-Verbindungsaufbau mit Füllbytes aufgefüllt werden. Hier hatte der Intranator einen Fehler, die Füllbytes wurden an der falschen Stelle eingefügt. Der Shrew-Client hat damit ein Problem, andere Clients nicht. Da die Füllbytes nur bei manchen Paketlängen nötig sind, hängt es u.a. von Domainname und Versionsnummer ab ob das Problem auftritt oder nicht.

Wir haben das jetzt korrigiert, die Füllbytes werden nun immer an der richtigen Stelle eingefügt. Diese Korrektur ist in Intranator Version 5.3.11 enthalten, die wir voraussichtlich heute Nachmittag freigeben werden. Ein anderer Shrew-Client oder eine Konfigurationsänderung ist nicht notwendig, es muß nur das Update über den regulären Weg eingespielt werden.

Herzliche Grüße,

v. Egidy

[Robin Ganter]

Hat funktioniert - besten Dank für die schnelle Hilfe