[Problem] Freetz OpenVPN TAP mit 7590

[M1234]

Hallo zusammen,
ich komme nicht mehr weiter. Ich habe von einer 7490 mit 6.92 auf eine 7590 mit 6.92 meine Konfigurationen übernommen (FritzOS sowie Freetz Sicherungsdatei). Bis auf das es einen die Kennwörter im FritzOS zerhaut hat dies auch alles funktioniert. Freetz wird von mir für OpenVPN Verbindungen eingesetzt, die Konfig wurde übernommen.

- Modul "tun" musste im WebIF von Freetz eingetragen werden, da dieses Modul ansonsten nicht läuft
- 2 OpenVPN TUN Konfigurationen laufen ohne Änderung problemlos
- 1 OpenVPN TAP Brücke funktioniert nicht mehr

Hat schon jemand mit den "neuen" Boxen ein TAP Tunnel erfolgreich zum laufen bekommen?

OpenVPN Ausgabe:

[INDENT]Wed Apr 11 11:30:31 2018 us=256612 OpenVPN 2.3.18 mips-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [IPv6] built on Apr 10 2018
Wed Apr 11 11:30:31 2018 us=256934 library versions: OpenSSL 1.0.2n  7 Dec 2017, LZO 2.10
Wed Apr 11 11:30:31 2018 us=259514 ******* WARNING *******: '--cipher none' was specified. This means NO encryption will be performed and tunnelled data WILL be transmitted in clear text over the network! PLEASE DO RECONSIDER THIS SETTING!
Wed Apr 11 11:30:31 2018 us=260897 Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Apr 11 11:30:31 2018 us=261112 Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Apr 11 11:30:31 2018 us=261192 crypto_adjust_frame_parameters: Adjusting frame parameters for crypto by 28 bytes
Wed Apr 11 11:30:31 2018 us=261458 Socket Buffers: R=[245760->245760] S=[245760->245760]
Wed Apr 11 11:30:31 2018 us=269323 TUN/TAP device tap2 opened
Wed Apr 11 11:30:31 2018 us=269500 TUN/TAP TX queue length set to 100
Wed Apr 11 11:30:31 2018 us=269663 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Wed Apr 11 11:30:31 2018 us=269861 /sbin/ifconfig tap2 192.168.0.1 netmask 255.255.255.254 mtu 1500 broadcast 192.168.0.1
Wed Apr 11 11:30:31 2018 us=281992 /sbin/route add -net 192.168.0.0 netmask 255.255.255.0 gw 192.168.0.1
route: SIOCADDRT: File exists
Wed Apr 11 11:30:31 2018 us=285605 ERROR: Linux route add command failed: external program exited with error status: 1
Wed Apr 11 11:30:31 2018 us=285901 Data Channel MTU parms [ L:1560 D:1450 EF:28 EB:12 ET:32 EL:3 AF:14/28 ]
Wed Apr 11 11:30:31 2018 us=286195 chroot to '/var/tmp/openvpn' and cd to '/' succeeded
Wed Apr 11 11:30:31 2018 us=286290 GID set to openvpn
Wed Apr 11 11:30:31 2018 us=286393 UID set to openvpn
Wed Apr 11 11:30:31 2018 us=286485 UDPv4 link local (bound): [undef]
Wed Apr 11 11:30:31 2018 us=286553 UDPv4 link remote: [undef]
Wed Apr 11 11:32:31 2018 us=987829 Inactivity timeout (--ping-restart), restarting
Wed Apr 11 11:32:31 2018 us=988839 TCP/UDP: Closing socket
Wed Apr 11 11:32:31 2018 us=989799 SIGUSR1[soft,ping-restart] received, process restarting
Wed Apr 11 11:32:31 2018 us=990371 Restart pause, 2 second(s)[/INDENT]

OpenVPN STATISTICS:

Updated,Wed Apr 11 12:44:40 2018
TUN/TAP read bytes,945
TUN/TAP write bytes,0
TCP/UDP read bytes,0
TCP/UDP write bytes,0
Auth read bytes,0
END

Routing Tabelle

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         *               0.0.0.0         U     2      0        0 dsl
***.***.***.***   *               255.255.255.255 UH    2      0        0 dsl
169.254.0.0     *               255.255.0.0     U     0      0        0 lan
192.168.0.0     *               255.255.255.254 U     0      0        0 tap2
192.168.0.0     fritz.box       255.255.255.0   UG    0      0        0 lan
192.168.0.0     *               255.255.255.0   U     0      0        0 lan
192.168.0.151   *               255.255.255.255 UH    2      0        0 dsl
192.168.10.1    *               255.255.255.255 UH    0      0        0 tun1
192.168.99.2    *               255.255.255.255 UH    0      0        0 tun0
192.168.178.0   192.168.10.1    255.255.255.0   UG    0      0        0 tun1
192.168.179.0   *               255.255.255.0   U     0      0        0 guest
192.168.180.1   *               255.255.255.255 UH    2      0        0 dsl
192.168.180.2   *               255.255.255.255 UH    2      0        0 dsl
217.0.43.1      *               255.255.255.255 UH    2      0        0 dsl
217.0.43.193    *               255.255.255.255 UH    2      0        0 dsl

Die Verbindung wird also aufgebaut, jedoch können keine Daten übertragen werden, woderuch der keep alive restart ausgelöst wird. Das tap2 Interface existiert. Die Route wird beim ersten starten ebenfalls angelegt (deshalb die Fehlermeldung "File exists").

 

[PeterPawn]

Die Maske für "tap2" sieht etwas komisch aus (.252 wäre nachvollziehbar) und die Route für 192.168.0.0/24 zeigt auf "dev lan" und nicht auf das "tap2"-Device.

Außerdem fehlt jede Information zur verwendeten Konfiguration bzw. das Debug-Level der Ausgaben ist bescheiden ... ich kann in dem gezeigten Protokoll nicht mal deutlich erkennen, ob das nun ein OpenVPN-Server ist (der auf eingehende Verbindungen wartet) oder ein Client. Insofern kann man auch die Feststellung:

Die Verbindung wird also aufgebaut

nicht so richtig nachvollziehen ... woran sieht man das jetzt genau?

Auch die Frage, wohin dieses "tap2"-Interface denn nun gebridged ist, wäre sicherlich nicht ganz uninteressant ... es könnten sich schon andere (lokale) Interface-Namen durch den Wechsel des FRITZ!Box-Modells ergeben. Also gehört da auch noch die Ausgabe von "brctl show" zu den notwendigen Informationen (zusätzlich zu den verwendeten Konfigurationsdateien bzw. überhaupt der Angabe, ob das nun mit dem v1- oder v2-Interface für OpenVPN konfiguriert wurde - bei v2 bist Du selbst für den Inhalt der Konfigurationsdateien verantwortlich).

Das sieht (für mich zumindest und mit den spärlichen Informationen) eher nach eine weiteren Konfiguration mit C&P aus, bei der nicht alles korrekt von der ersten geändert wurde. Mit der gezeigten Routing-Table ist jedenfalls über "tap2" ausschließlich die Adresse 192.168.0.0/32 und die Adresse 192.168.0.1/32 zu erreichen (das sind die beiden, die sich hinter 192.168.0.0/31 "verbergen") und nachdem das eine die Segment-Adresse ist und die andere die lokale IP für "tap2", habe ich ernsthafte Probleme, den Sinn dieser Konfiguration/Route zu erkennen - zumal diese 192.168.0.1/32 auch für keine andere Route im Netzwerk das Ziel wäre, wenn man der Routing-Table glauben will. Das ist also nicht nur ein Problem "beim zweiten Versuch" ... das ist (immer nur nach meiner bescheidenen Meinung) eine veritable Fehlkonfiguration.

 

[M1234]

Hi PeterPawn, erstmal vielen Dank für deine Antwort. Ich gebe dir recht, etliche Informationen fehlen. Es handelt sich um einen OpenVPN Server auf UDP Port 1200. Dieser Port lauscht auch reagiert im LAN auf Anfragen. Allerdings bin ich bei deiner Frage woran ich erkenne das der Tunnel steht nochmals in die Prüfung gegegangen und gebe dir recht, man sieht es an den Ausgaben nicht. Ich habe mich von Ausgaben auf dem Client täuschen lassen, der hat mir die Bound Addresse ausgegeben, die Ausgabe heißt allerdings nur das er die IP des Ziels auf Client Seite angibt. Die VPN Konfig habe ich über die "alte" V1 GUI erstellt. Hintergrund des TAP Device ist es das ein Client auf der anderen WAN Seite diese Fritzbox für Internet Traffic nutzt (Uni + Multicast Traffic). Das Device auf der anderen Seite soll also auch gar nichts anderes erreichen und ausschließlich diesen Internetanschluss benutzen (was auch funktionierte).

brctl show sieht gut aus:

root@fritz:/var/mod/root# brctl show
bridge name     bridge id               STP enabled     interfaces
lan             8000.e0286d6bcc20       no              wan
                                                        eth0
                                                        eth1
                                                        eth2
                                                        eth3
                                                        tap2
                                                        ath0
                                                        ath1
guest           8000.e0286d6bcc20       no

Problem ist das ich mit Loglevel 11 im OpenVPN Server auf der Fritzbox keine Anfragen von außen sehe. Ich hänge also an der Portfreigabe fest, welche ich mit dem Paket AVM-Forwarding durchführe. Egal in welcher Kombi (direkt neustart, warten usw.) ich die Freigabe erstelle wird sie wieder gelöscht. Hast du Erfahrung ob AVM-Forwarding überhaupt noch auf den Boxen funktioniert?

Ich hatte mich da leider von netstat fehlleiten lassen, dies zeigt mir ja nur das OpenVPN den Port lokal geöffnet hat...

 

[PeterPawn]

Dazu gibt es komplette Threads (Links habe ich auch keine parat und müßte sie erst suchen) ... zumindest meine eigenen Erfahrungen bestätigen das aber ebenfalls (diese Probleme beim Editieren) und anderslautende Erfahrungen kann ich nicht nachvollziehen.

Jedenfalls ist die Lösung normalerweise das Verlagern dieser Freigaben (von Hand editiert) in die "voip_forwardrules" (oder auch in die VPN-Konfiguration, wenn man das AVM-VPN zusätzlich verwendet - dort hinterlegte Freigaben werden nur dann aktiviert, wenn mind. eine VPN-Verbindung konfiguriert wurde) und das "Geheimnis" beim Editieren nur die richtige Reihenfolge beim Speichern von Änderungen und Stoppen/Starten von Diensten. Aber alles auch mehrfach beschrieben und - wenn man es automatisch richtig machen will - auch mit passenden Skript-Dateien vorbereitet: https://github.com/PeterPawn/YourFritz/blob/master/tffs/fritzos_scripts/tvi - da wird einem (wenn die Datei auf ".cfg" endet) auch noch das Stoppen/Starten des "ctlmgr" abgenommen.

Wobei man nach Änderungen an den Portfreigaben den "dsld" neu starten sollte (das macht "tvi" nicht mehr) ... am besten dann sogar die ganze Box, wenn man auf der ganz sicheren Seite sein will.

 

[M1234]

So nochmals besten Dank an dich PeterPawn! Ich habe die Beiträge gesucht und die ar7.cfg in der voip Sektion angepasst (hätte die AVM-VPN auch verfügbar gehabt, so ist es mir aber sicherer).

Für mich, falls ich es mal wieder brauche und auch falls jemand dieselben Probleme hat:
- In Freetz Weboberfläche muss unter Freetz/modules "tun" eingetragen werden, ansonsten wird das Modul nicht geladen und OpenVPN kann nicht arbeiten
- Portfreigabe muss in /var/flash/ar7.cfg in die Sektion:

voip_forwardrules = "udp 0.0.0.0:5060 0.0.0.0:5060",
"tcp 0.0.0.0:5060 0.0.0.0:5060",
diese Zeile, bspw.-> "udp 0.0.0.0:1200 0.0.0.0:1200",
"udp 0.0.0.0:7078+32 0.0.0.0:7078";

- Dafür muss man "ctlmgr -s" aufrufen um diesen zu stoppen
- Nun mit "nvi /var/flash/ar7.cfg" die Datei öffnen und die oben genannte Stelle suchen
- nvi funktioniert wie vi... Shift+I zum editieren/hinzufügen der Zeile, wenn fertig ESC Taste und :w und :q
- Box nun neustarten und nach reboot prüfen ob der hinzugefügte Eintrag noch vorhanden ist "grep -A 5 voip_forward /var/flash/ar7.cfg"

Hier noch die genutzten Threads: https://www.ip-phone-forum.de/threads/port-forwarding-using-cli.289859/ und https://www.ip-phone-forum.de/threads/gelöst-avm-forwarding-ar7-cfg-nicht-genug.287811/ und die Kommandos für nvi https://www.ip-phone-forum.de/threads/vi-und-nvi-auf-der-fritzbox.68201/