[Gelöst] 6490 OpenVPN startet nicht 7.25

[slashxxx]

Hallo, folgendes Log schreibt OpenVPN... Ich vermute das es mit dem Tun-Device zutun hat... es taucht in Freetz nicht mehr auf (die Konfig funktioniert unter 7.12 bei 7.25 nicht mehr):

2021-04-18 12:55:40 Cipher negotiation is disabled since neither P2MP client nor server mode is enabled
2021-04-18 12:55:40 OpenVPN 2.5.1 i686-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [AEAD] built on Apr  5 2021
2021-04-18 12:55:40 library versions: OpenSSL 1.1.1k  25 Mar 2021, LZO 2.10
2021-04-18 12:55:40 WARNING: INSECURE cipher (BF-CBC) with block size less than 128 bit (64 bit).  This allows attacks like SWEET32.  Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). Support for these insecure ciphers will be removed in OpenVPN 2.6.
2021-04-18 12:55:40 Outgoing Static Key Encryption: Cipher 'BF-CBC' initialized with 128 bit key
2021-04-18 12:55:40 WARNING: INSECURE cipher (BF-CBC) with block size less than 128 bit (64 bit).  This allows attacks like SWEET32.  Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). Support for these insecure ciphers will be removed in OpenVPN 2.6.
2021-04-18 12:55:40 Outgoing Static Key Encryption: Using 160 bit message hash 'SHA1' for HMAC authentication
2021-04-18 12:55:40 Incoming Static Key Encryption: Cipher 'BF-CBC' initialized with 128 bit key
2021-04-18 12:55:40 WARNING: INSECURE cipher (BF-CBC) with block size less than 128 bit (64 bit).  This allows attacks like SWEET32.  Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). Support for these insecure ciphers will be removed in OpenVPN 2.6.
2021-04-18 12:55:40 Incoming Static Key Encryption: Using 160 bit message hash 'SHA1' for HMAC authentication
2021-04-18 12:55:40 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1300)
2021-04-18 12:55:41 TUN/TAP device tun0 opened
2021-04-18 12:55:41 /sbin/ip link set dev tun0 up mtu 1300
2021-04-18 12:55:41 /sbin/ip link set dev tun0 up
2021-04-18 12:55:41 /sbin/ip addr add dev tun0 local 192.168.20.1 peer 192.168.10.1
2021-04-18 12:55:41 /sbin/ip route add 192.168.10.0/24 via 192.168.10.1
2021-04-18 12:55:41 TCP/UDP: Preserving recently used remote address: [AF_INET6]xxxx:xx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:1194
2021-04-18 12:55:41 Socket Buffers: R=[176128->176128] S=[176128->176128]
2021-04-18 12:55:41 UDP link local: (not bound)
2021-04-18 12:55:41 UDP link remote: [AF_INET6]xxxx:xx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:1194
2021-04-18 12:55:41 chroot to '/var/tmp/openvpn' and cd to '/' succeeded
2021-04-18 12:55:41 GID set to openvpn
2021-04-18 12:55:41 UID set to openvpn
2021-04-18 12:55:41 OpenSSL: error:2406C06E:lib(36):func(108):reason(110)
2021-04-18 12:55:41 OpenSSL: error:2406C06E:lib(36):func(108):reason(110)
2021-04-18 12:55:41 OpenSSL: error:2406B072:lib(36):func(107):reason(114)
2021-04-18 12:55:41 OpenSSL: error:2406C06E:lib(36):func(108):reason(110)
2021-04-18 12:55:41 OpenSSL: error:2406C06E:lib(36):func(108):reason(110)
2021-04-18 12:55:41 OpenSSL: error:2406B072:lib(36):func(107):reason(114)
2021-04-18 12:55:41 OpenSSL: error:2406C06E:lib(36):func(108):reason(110)
2021-04-18 12:55:41 OpenSSL: error:2406B072:lib(36):func(107):reason(114)
2021-04-18 12:55:41 RAND_bytes() failed
2021-04-18 12:55:41 Assertion failed at crypto.c:1773
2021-04-18 12:55:41 Exiting due to fatal error
2021-04-18 12:55:41 /sbin/ip route del 192.168.10.0/24
2021-04-18 12:55:41 ERROR: Linux route delete command failed: could not execute external program
2021-04-18 12:55:41 Closing TUN/TAP interface
2021-04-18 12:55:41 /sbin/ip addr del dev tun0 local 192.168.20.1 peer 192.168.10.1
2021-04-18 12:55:41 Linux ip addr del failed: could not execute external program

 

[PeterPawn]

Ich vermute das es mit dem Tun-Device zutun hat

Ich eher nicht ... das liegt aber daran, daß die zwei protokollierten Fehlercodes eher in die Richtung "Entropy" verweisen und da wohl (ggf. auch erst nach dem Wechsel von UID und GID - EDIT: bzw. ins chroot-Jail) irgendetwas mit /dev/[u]random nicht stimmt.

vidar:~ $ openssl errstr 2406C06E
error:2406C06E:random number generator:RAND_DRBG_instantiate:error retrieving entropy
vidar:~ $ openssl errstr 2406B072
error:2406B072:random number generator:RAND_DRBG_generate:in error state
vidar:~ $

Auch das "Fazit" in OpenVPN (in der Funktion rand_bytes(), die ihrerseits das RAND_bytes() von OpenSSL aufruft): 2021-04-18 12:55:41 RAND_bytes() failed deutet ja nun so absolut nicht in die Richtung des TUN-Devices, zumal auch dessen Öffnen noch funktioniert hat, wenn man dem Protokoll Glauben schenken wollte.

 

[slashxxx]

okay, danke für die Info. Anscheinend bist du der Profi, ich vertraue dir
Leider reicht mein Wissen nicht aus um hier weiter zu kommen...
Kann ich euch noch etwas zur Verfügung stellen?
Danke vorab.

PS: Im Freetz-Log stand folgendes: modprobe: module tun not found in modules.dep

 

[PeterPawn]

Irgendetwas/irgendwer muß ja das chroot-Jail in /var/tmp/openvpn vorbereiten, wenn das in der Konfiguration dann verwendet werden soll. Als erstes würde ich da mal nachsehen, ob tatsächlich die notwendigen Device-Inodes auch existieren ... und zwar IM Jail.

Oder man läßt eben die Einstellung mit dem chroot einfach mal weg ... zumindest kriegt man dann ja heraus, ob es daran liegt oder nicht und "reparieren" kann man das dann ohnehin besser, wenn man erst mal die Ursache kennt (oder sie Stück für Stück weiter "umzingelt").

 

[feedzapper]

Ich glaube einfach, dass openssl nicht mit BLOWFISH compiliert wurde - dieser cipher aber in der in der Openvpn.conf gesetzt wurde.
Dies führt dann vermutlich zu dieser Fehlermeldung von OpenSSL.
Einfach mal mit "data-ciphers AES-256-GCM" in der openvpn.conf probieren b.z.w "cipher AES-256-GCM" für ältere OpenVPN versionen.

 

[PeterPawn]

Was - außer Deinem festen Glauben - sollte denn noch dafür sprechen? Die Fehlermeldungen im Protokoll sind eindeutig und ich habe sogar auf die Stelle im (OpenVPN-)Quelltext verwiesen (wenn auch nicht verlinkt), wo sie ausgegeben wird.

Wo ist da Blowfish überhaupt auch nur in der Nähe? Das ist ein expliziter Aufruf, um Zufallsdaten zu erhalten - direkt aus dem OpenVPN-Code und hat mit irgendeiner Initialisierung eines Cipher-Algorithmus (von wo aus dann diese Stelle irgendwie "indirekt" aufgerufen werden könnte) praktisch nichts zu tun.

Hast Du mal geprüft, was OpenVPN ins Protokoll ausgibt, wenn BF-CBC tatsächlich nicht zur Verfügung steht?

Ich sehe jedenfalls im Quelltext, daß die im Log in #1 sichtbaren Nachrichten nur dann ausgegeben werden, wenn ein Kontext erfolgreich(!) initialisiert wurde:

817 /* given a key and key_type, build a key_ctx */
818 void
819 init_key_ctx(struct key_ctx *ctx, const struct key *key,
820              const struct key_type *kt, int enc,
821              const char *prefix)
822 {
823     struct gc_arena gc = gc_new();
824     CLEAR(*ctx);
825     if (kt->cipher && kt->cipher_length > 0)
826     {
827
828         ctx->cipher = cipher_ctx_new();
829         cipher_ctx_init(ctx->cipher, key->cipher, kt->cipher_length,
830                         kt->cipher, enc);
831
832         const char *ciphername = cipher_kt_name(kt->cipher);
833         msg(D_HANDSHAKE, "%s: Cipher '%s' initialized with %d bit key",
834             prefix,
835             ciphername,
836             kt->cipher_length *8);
837
838         dmsg(D_SHOW_KEYS, "%s: CIPHER KEY: %s", prefix,
839              format_hex(key->cipher, kt->cipher_length, 0, &gc));
840         dmsg(D_CRYPTO_DEBUG, "%s: CIPHER block_size=%d iv_size=%d",
841              prefix, cipher_kt_block_size(kt->cipher),
842              cipher_kt_iv_size(kt->cipher));
843         warn_insecure_key_type(ciphername, kt->cipher);
844     }
845     if (kt->digest && kt->hmac_length > 0)
846     {
847         ctx->hmac = hmac_ctx_new();
848         hmac_ctx_init(ctx->hmac, key->hmac, kt->hmac_length, kt->digest);
849
850         msg(D_HANDSHAKE,
851             "%s: Using %d bit message hash '%s' for HMAC authentication",
852             prefix, md_kt_size(kt->digest) * 8, md_kt_name(kt->digest));
853
854         dmsg(D_SHOW_KEYS, "%s: HMAC KEY: %s", prefix,
855              format_hex(key->hmac, kt->hmac_length, 0, &gc));
856
857         dmsg(D_CRYPTO_DEBUG, "%s: HMAC size=%d block_size=%d",
858              prefix,
859              md_kt_size(kt->digest),
860              hmac_ctx_size(ctx->hmac));
861
862     }
863     gc_free(&gc);
864 }

(aus src/openvpn/crypto.c im OpenVPN und damit man sich da auch die Historie ansehen kann (wie lange das schon so ist), verlinke ich nun doch mal dorthin: https://github.com/OpenVPN/openvpn/...f18a921a5d29c9b10b3/src/openvpn/crypto.c#L833)

... und das wäre schwerlich möglich, wenn "das Problem" am Fehlen des notwendigen Crypto-Supports in der OpenSSL-Crypto-Library liegen soll(te).

Kleiner Tipp/Ausflug in den Quellcode zum Abschluß: So sähe die Fehlermeldung aus, wenn in cipher_kt_get() (https://github.com/OpenVPN/openvpn/...5d29c9b10b3/src/openvpn/crypto_openssl.c#L585) festgestellt würde, daß der gewünschte Algorithmus nicht verfügbar ist: https://github.com/OpenVPN/openvpn/...f18a921a5d29c9b10b3/src/openvpn/crypto.c#L755

ICH halte das also eher für einen Irrglauben ... aber ich habe von Glaubensfragen tatsächlich auch fast gar keine Ahnung.

 

[ds77]

Bei der 6590 kommt derselbe Fehler mit Firmware 7.25 und 7.27. Andere FB's (7490, 7590) funktionieren hingegen korrekt.

Irgendetwas/irgendwer muß ja das chroot-Jail in /var/tmp/openvpn vorbereiten, wenn das in der Konfiguration dann verwendet werden soll. Als erstes würde ich da mal nachsehen, ob tatsächlich die notwendigen Device-Inodes auch existieren ... und zwar IM Jail.

Oder man läßt eben die Einstellung mit dem chroot einfach mal weg ... zumindest kriegt man dann ja heraus, ob es daran liegt oder nicht und "reparieren" kann man das dann ohnehin besser, wenn man erst mal die Ursache kennt (oder sie Stück für Stück weiter "umzingelt").

Könntest du das etwas genauer erklären, wie man das macht.

 

[PeterPawn]

Könntest du das etwas genauer erklären, wie man das macht.

Eigentlich nicht, weil "nicht mein Tisch" ... aber als kleiner Tipp meinerseits bzw. was ich in dieser Situation als erstes "probieren" würde:

Diese Zeile: https://github.com/Freetz-NG/freetz...nvpn-cgi/files/root/etc/init.d/rc.openvpn#L27 in der rc.openvpn verdoppeln und dieses Duplikat auf /dev/random und Minor-ID 8 (das wäre die für /dev/random) ändern.

Meine Vermutung(!) ist es, daß da eines der beteiligten Software-Pakete (ich würde auf OpenSSL tippen, wobei es auch Änderungen in OpenVPN gegeben haben könnte) sich nicht länger mit zuviel Pseudo-Entropie zufrieden geben will (/dev/urandom liefert - im Gegensatz zu /dev/random - immer irgendwelche Daten beim Leseversuch und blockiert nicht, wenn diese Daten gar nicht wirklich "zufällig" sind) und stattdessen auf besseren Daten beharrt. Dieses Device wird aber - das sind die Zeilen davor und dahinter - im chroot-Jail gar nicht erzeugt - daher wird (vermutlich) auch der Leseversuch in die Hose gehen. Ansonsten käme noch ein Problem beim Einrichten des Device-Nodes für /dev/urandom in Betracht ... aber das wäre erst mein zweiter Punkt, wenn es auch mit einem zusätzlichen /dev/random nicht funktioniert.

---

Alternativ kann man aber auch einfach das andere GUI-Paket für OpenVPN benutzen (openvpn-v2-cgi) ... dort kann man selbst dafür sorgen, daß eben kein chroot-Jail benutzt wird (was beim Paket openvpn-cgi unumgänglich ist: https://github.com/Freetz-NG/freetz...es/root/etc/default.openvpn/openvpn_conf#L236), indem man die chroot-Anweisung in der Konfigurationsdatei einfach ausläßt und damit auch die Geräte aus dem "normalen" FRITZ!OS bzw. Freetz zugänglich bleiben. Ich würde die geringe Resonanz bei diesem Problem auch darauf zurückführen, daß die meisten eben dieses alternative GUI für OpenVPN benutzen bzw. daß in früheren Builds vermutlich auch noch /dev/urandom als "letzte Instanz" genutzt wurde und das wird ja auch beim älteren GUI-Paket in /tmp/openvpn erzeugt.

Wie weit es beim generellen Aufbau des FRITZ!OS bzw. von Freetz tatsächlich hilft, einem Programm zur Isolation vom Rest des Systems ein eigenes Wurzeldateisystem zu verordnen, lassen wir mal dahingestellt ... wer das auch mit dem anderen GUI-Paket realisieren will, kann/muß dann aber auch diese Verzeichnisstruktur selbst (und am besten auch noch dynamisch) einrichten, dann die andere rc.openvpn enthält auch dafür keinerlei Vorbereitung.

---

EDIT: Und falls sich jemand die Frage stellt, warum ich auf diese Ursache für das Problem tippe, obwohl das ja auf anderen Modellen auch funktioniert ... die Puma-Boxen sind die einzigen, die eine x86-Architektur (auf dem Core, wo die Modifikationen auch laufen) verwenden und diese bringt - auch wg. der Verbreitung von Intel- und AMD-CPUs bei PCs und Servern - einiges an Optimierungen/Änderungen für diese Architektur (und auch für x86_64) in den beteiligten Paketen mit sich. Und auf x86-Systemen existiert schon seit geraumer Zeit ein zusätzlicher Prozess (haveged - https://linux.die.net/man/8/haveged), der seinerseits dafür sorgt/sorgen soll, daß auch /dev/random stets über einen ausreichend gefüllten Entropie-Pool verfügt und /dev/urandom nur noch genutzt werden muß, wenn es nicht wirklich auf Zufallsdaten ankommt bzw. wenn deren Qualität keine Rolle spielt (was bei VPN-Verbindungen schon mal nicht der Fall wäre).

 

[ds77]

@PeterPawn: Ein

mknod -m 444 /tmp/openvpn/dev/random c 1 8 2>/dev/null

tut es tatsächlich. Vielen Dank für deinen Tipp. Und schon startet OpenVPN auf einem Puma-Device. Ich werde die Änderung mal im entsprechenden freetz Ticket vorschlagen. Darf ich dich zitieren?

 

[PeterPawn]

@cuma liest hier (häufig) mit ... was man auch daran erkennt, wenn Änderungen an Freetz-NG erfolgen, nachdem hier Lösungen gefunden wurden. Üblicherweise verlinkt er dann auch selbst auf die entsprechenden IPPF-Threads - das reicht vermutlich auch bei Deiner Meldung in GitHub dann aus.

Aber es freut mich, daß meine "Ahnung" nicht getrogen hat ... ... auch wenn die exakte Änderung (in den beteiligten Paketen), die dieses Verhalten bewirkt, nicht genau ermittelt wurde.

 

[ds77]

Wurde behoben, siehe https://github.com/Freetz-NG/freetz-ng/issues/299
@slashxxx: Kannst du den Thread auf gelöst setzen. Damit sollte das Problem sowohl bei der 6490 als auch den anderen Puma-Boxen gelöst sein.

 

[PeterPawn]

Nein, kann ich nicht ... ist ja nicht meiner und ich habe keinerlei Sonderrechte. Das müßte schon @slashxxx machen (wobei die "Präfixliste" m.W. auch Opfer eines der letztes Updates geworden ist?) oder eben ein Moderator.

 

[stoney]

wobei die "Präfixliste" m.W. auch Opfer eines der letztes Updates geworden ist?) oder eben ein Moderator.

erledigt und intern "gemeldet" war mir bislang nicht bekannt... verrät einem aber auch keiner was --_--