Hallo zusammen,
nach Jahren des "phasenweisen Intensivlesens" hier im Forum und Nutzung des einzigartigen modfs von PeterPawn ist dies heute mein erstes Posting.
Im Jahr 2017 konnte ich zu meiner FB-7490 mit modfs-4.5-FW-6.83 und in-Box-OpenVPN-Server erfolgreich tunneln.
Seitdem habe ich Updates auf modfs-5.4-FW-7.01 und jüngst auf modfs-6.1-FW-7.12 durchgeführt.
Erst bei letzterem fiel mir nun auf, dass bereits das bloße STARTEN eines einfachst konfigurierten OpenVPN-Clients unter Ubuntu-18.04 auf einem Mobil-PC ...
... (vor dessen manueller Beendigung) reproduzierbar zum sofortigen REBOOT der FB-7490 unter modfs-6.1-Fritz-OS-7.12 mit darin zuvor aktiviertem OpenVPN-Server führt
Das openvpn-Binary stammt ebenfalls aus @PeterPawns Yourfritz-Repository.
Die ar7.cfg hatte ich zuvor mit der folgenden 3. + 4. Zeile in den voip_forwardrules reboot-fest gepatcht
Dann habe ich einen Neustart auf das andere Partition-Set mit der Vorgänger-Version modfs-5.4-FW-7.01 gemacht und wieder genau so OpenVPN-Server und -Client gestartet, was ebenfalls zum "automatischen" REBOOT führte.
Schließlich habe ich "gewagt", die "alte" ehemalige Version FW-6.83 (jetzt mit modfs-6.1 statt damals -4.5) in das andere Partition-Set zu flashen.
Das ist die FW, die noch im Jahr 2017 hinsichtlich der OpenVPN-Server-Verwendung "gutmütig", d.h. ohne Reboot-Seiteneffekt, funktionierte ...
... und siehe da, der Tunnel baute sich wieder anstandslos auf - es kam also NICHT zum Reboot - und PINGs an das Tunnel-Ende 10.0.0.1 waren erfolgreich!
Gegen einen denkbaren Speicher-Engpaß bei den neueren FW-Versionen spricht mMn die Tatsache, dass im WebUI noch ca. 305 MB freier Speicher angezeigt wurden.
Dennoch hatte ich auch einen Test inkl. zusätzlichem 1GB-Swapfile gemacht, was den Reboot aber auch nicht verhindern konnte.
Nun bin ich einigermaßen ratlos, was (mindestens) die beiden neuesten FW-Versionen derart "sensibel" macht.
Hat hier jemand
Danke schon mal für Euer Interesse!
nach Jahren des "phasenweisen Intensivlesens" hier im Forum und Nutzung des einzigartigen modfs von PeterPawn ist dies heute mein erstes Posting.
Im Jahr 2017 konnte ich zu meiner FB-7490 mit modfs-4.5-FW-6.83 und in-Box-OpenVPN-Server erfolgreich tunneln.
Seitdem habe ich Updates auf modfs-5.4-FW-7.01 und jüngst auf modfs-6.1-FW-7.12 durchgeführt.
Erst bei letzterem fiel mir nun auf, dass bereits das bloße STARTEN eines einfachst konfigurierten OpenVPN-Clients unter Ubuntu-18.04 auf einem Mobil-PC ...
Code:
sudo openvpn --secret file.txt --dev tun0 --port 6443 --proto tcp4-client --ifconfig 10.0.0.2 10.0.0.1 --remote 444.333.222.111
Fri Aug 14 20:03:29 2020 disabling NCP mode (--ncp-disable) because not in P2MP client or server mode
Fri Aug 14 20:03:29 2020 WARNING: file 'file.txt' is group or others accessible
Fri Aug 14 20:03:29 2020 OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 14 2019
Fri Aug 14 20:03:29 2020 library versions: OpenSSL 1.1.1 11 Sep 2018, LZO 2.08
Fri Aug 14 20:03:29 2020 WARNING: INSECURE cipher 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).
Fri Aug 14 20:03:29 2020 WARNING: INSECURE cipher 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).
Fri Aug 14 20:03:29 2020 TUN/TAP device tun0 opened
Fri Aug 14 20:03:29 2020 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Fri Aug 14 20:03:29 2020 /sbin/ip link set dev tun0 up mtu 1500
Fri Aug 14 20:03:29 2020 /sbin/ip addr add dev tun0 local 10.0.0.2 peer 10.0.0.1
Fri Aug 14 20:03:29 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]444.333.222.111:6443
Fri Aug 14 20:03:29 2020 Attempting to establish TCP connection with [AF_INET]444.333.222.111:6443 [nonblock]
Fri Aug 14 20:03:30 2020 TCP connection established with [AF_INET]444.333.222.111:6443
Fri Aug 14 20:03:30 2020 TCPv4_CLIENT link local: (not bound)
Fri Aug 14 20:03:30 2020 TCPv4_CLIENT link remote: [AF_INET]444.333.222.111:6443
===> manuelle Beendigung
^CFri Aug 14 20:04:59 2020 event_wait : Interrupted system call (code=4)
Fri Aug 14 20:04:59 2020 /sbin/ip addr del dev tun0 local 10.0.0.2 peer 10.0.0.1
Fri Aug 14 20:04:59 2020 SIGINT[hard,] received, process exiting
... (vor dessen manueller Beendigung) reproduzierbar zum sofortigen REBOOT der FB-7490 unter modfs-6.1-Fritz-OS-7.12 mit darin zuvor aktiviertem OpenVPN-Server führt
Code:
# var/InternerSpeicher/OpenVPN/openvpn --secret var/InternerSpeicher/OpenVPN/file.txt --dev tun0 --port 6443 --proto tcp4-server --ifconfig 10.0.0.1 10.0.0.2
Fri Aug 14 20:01:55 2020 disabling NCP mode (--ncp-disable) because not in P2MP client or server mode
Fri Aug 14 20:01:55 2020 WARNING: file 'var/InternerSpeicher/OpenVPN/file.txt' is group or others accessible
Fri Aug 14 20:01:55 2020 OpenVPN 2.4.6 mips-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [AEAD] built on Oct 28 2018
Fri Aug 14 20:01:55 2020 library versions: OpenSSL 1.0.2p 14 Aug 2018, LZO 2.10
Fri Aug 14 20:01:55 2020 WARNING: INSECURE cipher 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).
Fri Aug 14 20:01:55 2020 WARNING: INSECURE cipher 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).
Fri Aug 14 20:01:55 2020 TUN/TAP device tun0 opened
Fri Aug 14 20:01:55 2020 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Fri Aug 14 20:01:55 2020 /sbin/ifconfig tun0 10.0.0.1 pointopoint 10.0.0.2 mtu 1500
Fri Aug 14 20:01:55 2020 Listening for incoming TCP connection on [AF_INET][undef]:6443
Fri Aug 14 20:03:29 2020 TCP connection established with [AF_INET]109.42.3.109:19668
Fri Aug 14 20:03:29 2020 TCPv4_SERVER link local (bound): [AF_INET][undef]:6443
Fri Aug 14 20:03:29 2020 TCPv4_SERVER link remote: [AF_INET]109.42.3.109:19668
===> "automatischer" REBOOT
Das openvpn-Binary stammt ebenfalls aus @PeterPawns Yourfritz-Repository.
Die ar7.cfg hatte ich zuvor mit der folgenden 3. + 4. Zeile in den voip_forwardrules reboot-fest gepatcht
Code:
voip_forwardrules = "udp 0.0.0.0:5060 0.0.0.0:5060",
"tcp 0.0.0.0:5060 0.0.0.0:5060",
"tcp 0.0.0.0:443 0.0.0.0:40000",
"tcp 0.0.0.0:6443 0.0.0.0:6443",
"udp 0.0.0.0:7078+32 0.0.0.0:7078";
Dann habe ich einen Neustart auf das andere Partition-Set mit der Vorgänger-Version modfs-5.4-FW-7.01 gemacht und wieder genau so OpenVPN-Server und -Client gestartet, was ebenfalls zum "automatischen" REBOOT führte.
Schließlich habe ich "gewagt", die "alte" ehemalige Version FW-6.83 (jetzt mit modfs-6.1 statt damals -4.5) in das andere Partition-Set zu flashen.
Das ist die FW, die noch im Jahr 2017 hinsichtlich der OpenVPN-Server-Verwendung "gutmütig", d.h. ohne Reboot-Seiteneffekt, funktionierte ...
... und siehe da, der Tunnel baute sich wieder anstandslos auf - es kam also NICHT zum Reboot - und PINGs an das Tunnel-Ende 10.0.0.1 waren erfolgreich!
Gegen einen denkbaren Speicher-Engpaß bei den neueren FW-Versionen spricht mMn die Tatsache, dass im WebUI noch ca. 305 MB freier Speicher angezeigt wurden.
Dennoch hatte ich auch einen Test inkl. zusätzlichem 1GB-Swapfile gemacht, was den Reboot aber auch nicht verhindern konnte.
Nun bin ich einigermaßen ratlos, was (mindestens) die beiden neuesten FW-Versionen derart "sensibel" macht.
Hat hier jemand
- ähnliche Erfahrungen gemacht,
- eine Idee
- oder gar Erkenntnis
Danke schon mal für Euer Interesse!
Zuletzt bearbeitet: