Quantcast
Aktuelles
Digital Eliteboard - Das Digitale Technik Forum

Registriere dich noch heute kostenlos, um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereichen, welche für Gäste verwehrt bleiben

Registriere dich noch heute kostenlos, um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereichen, welche für Gäste verwehrt bleiben

Support Fritzbox 7412 OpenVPN Client

pascalts

Newbie
Registriert
3. Januar 2021
Beiträge
3
Reaktionspunkte
0
Punkte
21
Moin!

Ich habe auf meiner kleinen AVM Fritzbox 7412 erfolgreich freetz (ohne ng) geflasht mit den zusätzlichen Paketen von openvpn, openssh und nano. Derzeit versuche ich den gesamten Internetverkehr durch einen openvpn-Tunnel zu leiten, die Fritte soll also als openvpn-client laufen. Ich habe ein Abo bei surfshark, deren openvpn-Konfiguationen haben bisher immer gut funktioniert bei mir.

Nun scheitere ich ein wenig an der Konfiguration. Ich kann, dank der neuen GUI ( ) meine config direkt "reinwerfen". Dann kann ich den Deinst starten. Das klappt alles soweit gut, das Tunnel-Interface wird angelegt und wenn ich mich per SSH einwähle und eine Traceroute starte, dann sehe ich auch, dass die Daten über den Tunnel laufen.

ABER: Alle angeschlossenen LAN- und WLAN-Geräte kommen ab dem Moment nicht mehr ins Internet. Ich vermute das es da noch ein Routing-Problem gibt, oder ich eine Konfiguration missverstanden oder übersehen habe. Kann mich jemand aufklären?

Hier meine Config:

Code:
client
dev tun
proto udp
remote [ZENSUR.de] 1194
resolv-retry infinite
remote-random
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-key
persist-tun
ping 15
ping-restart 0
ping-timer-rem
reneg-sec 0

remote-cert-tls server

auth-user-pass [PFAD/ZUR/DATEI]

#comp-lzo
verb 3
pull
fast-io
cipher AES-256-CBC

auth SHA512

<ca>
-----BEGIN CERTIFICATE-----
[ZENSUR]
-----END CERTIFICATE-----
</ca>
key-direction 1
<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
[ZENSUR]
-----END OpenVPN Static key V1-----
</tls-auth>

Gruß

Pascal

PS: Hier das Syslog:

Code:
n 3 13:42:48 fritz daemon.notice openvpn[10089]: OpenVPN 2.4.9 mips-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [AEAD] built on Jan  1 2021
Jan  3 13:42:48 fritz daemon.notice openvpn[10089]: library versions: OpenSSL 1.0.2u  20 Dec 2019, LZO 2.10
Jan  3 13:42:48 fritz daemon.warn openvpn[10090]: WARNING: --ping should normally be used with --ping-restart or --ping-exit
Jan 3 13:42:48 fritz daemon.notice openvpn[10090]: Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Jan  3 13:42:48 fritz daemon.notice openvpn[10090]: Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Jan  3 13:42:48 fritz daemon.notice openvpn[10090]: TCP/UDP: Preserving recently used remote address: [AF_INET][ZENSUR]:1194
Jan  3 13:42:48 fritz daemon.notice openvpn[10090]: Socket Buffers: R=[229376->229376] S=[229376->229376]
Jan  3 13:42:48 fritz daemon.notice openvpn[10090]: UDP link local: (not bound)
Jan  3 13:42:48 fritz daemon.notice openvpn[10090]: UDP link remote: [AF_INET][ZENSUR]:1194
Jan  3 13:42:48 fritz daemon.notice openvpn[10090]: TLS: Initial packet from [AF_INET][ZENSUR]:1194, sid=[ZENSUR]
Jan 3 13:42:48 fritz daemon.warn openvpn[10090]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Jan  3 13:42:49 fritz daemon.notice openvpn[10090]: VERIFY OK: depth=2, C=VG, O=Surfshark, CN=Surfshark Root CA
Jan  3 13:42:49 fritz daemon.notice openvpn[10090]: VERIFY OK: depth=1, C=VG, O=Surfshark, CN=Surfshark Intermediate CA
Jan  3 13:42:49 fritz daemon.notice openvpn[10090]: VERIFY KU OK
Jan  3 13:42:49 fritz daemon.notice openvpn[10090]: Validating certificate extended key usage
Jan 3 13:42:49 fritz daemon.notice openvpn[10090]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Jan  3 13:42:49 fritz daemon.notice openvpn[10090]: VERIFY EKU OK
Jan  3 13:42:49 fritz daemon.notice openvpn[10090]: VERIFY OK: depth=0, CN=[ZENSUR]
Jan 3 13:42:49 fritz daemon.warn openvpn[10090]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1633', remote='link-mtu 1581'
Jan 3 13:42:49 fritz daemon.warn openvpn[10090]: WARNING: 'cipher' is used inconsistently, local='cipher AES-256-CBC', remote='cipher AES-256-GCM'
Jan 3 13:42:49 fritz daemon.warn openvpn[10090]: WARNING: 'auth' is used inconsistently, local='auth SHA512', remote='auth [null-digest]'
Jan 3 13:42:49 fritz daemon.notice openvpn[10090]: Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Jan  3 13:42:49 fritz daemon.notice openvpn[10090]: [[ZENSUR]] Peer Connection Initiated with [AF_INET][ZENSUR]:1194
Jan  3 13:42:50 fritz daemon.notice openvpn[10090]: SENT CONTROL [ZENSUR]]: 'PUSH_REQUEST' (status=1)
Jan 3 13:42:50 fritz daemon.notice openvpn[10090]: PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS [ZENSUR],dhcp-option DNS [ZENSUR],redirect-gateway def1,sndbuf 524288,rcvbuf 524288,explicit-exit-notify,block-outside-dns,route-gateway 10.8.8.1,t
Jan 3 13:42:50 fritz daemon.err openvpn[10090]: Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:7: block-outside-dns (2.4.9)
Jan  3 13:42:50 fritz daemon.notice openvpn[10090]: OPTIONS IMPORT: timers and/or timeouts modified
Jan  3 13:42:50 fritz daemon.notice openvpn[10090]: OPTIONS IMPORT: explicit notify parm(s) modified
Jan  3 13:42:50 fritz daemon.notice openvpn[10090]: OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Jan  3 13:42:50 fritz daemon.notice openvpn[10090]: Socket Buffers: R=[229376->458752] S=[229376->458752]
Jan  3 13:42:50 fritz daemon.notice openvpn[10090]: OPTIONS IMPORT: --ifconfig/up options modified
Jan  3 13:42:50 fritz daemon.notice openvpn[10090]: OPTIONS IMPORT: route options modified
Jan  3 13:42:50 fritz daemon.notice openvpn[10090]: OPTIONS IMPORT: route-related options modified
Jan  3 13:42:50 fritz daemon.notice openvpn[10090]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Jan  3 13:42:50 fritz daemon.notice openvpn[10090]: OPTIONS IMPORT: peer-id set
Jan  3 13:42:50 fritz daemon.notice openvpn[10090]: OPTIONS IMPORT: adjusting link_mtu to 1656
Jan  3 13:42:50 fritz daemon.notice openvpn[10090]: OPTIONS IMPORT: data channel crypto options modified
Jan  3 13:42:50 fritz daemon.notice openvpn[10090]: Data Channel: using negotiated cipher 'AES-256-GCM'
Jan  3 13:42:50 fritz daemon.notice openvpn[10090]: Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Jan  3 13:42:50 fritz daemon.notice openvpn[10090]: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Jan  3 13:42:50 fritz daemon.notice openvpn[10090]: TUN/TAP device tun0 opened
Jan  3 13:42:50 fritz daemon.notice openvpn[10090]: TUN/TAP TX queue length set to 100
Jan 3 13:42:50 fritz daemon.notice openvpn[10090]: /sbin/ifconfig tun0 10.8.8.11 netmask 255.255.255.0 mtu 1500 broadcast 10.8.8.255
Jan  3 13:42:50 fritz daemon.notice openvpn[10090]: /sbin/route add -net [ZENSUR] netmask 255.255.255.255 dev dsl
Jan  3 13:42:50 fritz daemon.notice openvpn[10090]: /sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 10.8.8.1
Jan  3 13:42:50 fritz daemon.notice openvpn[10090]: /sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 10.8.8.1
Jan  3 13:42:50 fritz daemon.notice openvpn[10090]: Initialization Sequence Completed
 
Zuletzt bearbeitet von einem Moderator:
vermute jedes Gerät muss einen Clieten starten, da du den gesamten Internetverkehr umleitest.
 
Neee, ich glaube du missverstehst mich: Die Fritzbox agiert als Client. Der Server steht "irgendwo im Internet". Ziel ist es, meinen Datenverkehr "am Provider vorbei" zu schleusen. Meine Fritte soll quasi den ausgehenden Netzwerkverkehr, den sie ja eh über das DSl-Interface routet, zusätzlich durch den Tunnel jagen.
 
ist nachvollziehbar. So läufts doch bei vielen, oder kanns einer von Profis weiter helfen?
 
man Liest mit und wenn der fachkundige Zeit hat, gibts Infos. Sorry...
 
ABER: Alle angeschlossenen LAN- und WLAN-Geräte kommen ab dem Moment nicht mehr ins Internet. Ich vermute das es da noch ein Routing-Problem gibt, oder ich eine Konfiguration missverstanden oder übersehen habe. Kann mich jemand aufklären?

Hallo! :cool:

Bisher habe ich ausschließlich ASUS-Router mit DD-WRT genutzt, da ich nur DSL hatte. Nach Umstieg auf Vodafone KD habe ich mit zunächst zum Testen eine Fritz!Cable 6490 zugelegt. Es läuft darauf derzeit FritzOS 07.24-86472 BETA vom 19.02. Da ich gerne mit der Box OpenVPN nutzen möchte, lese ich gerade ein paar Beiträge dazu und freue mich zu lesen, dass es offensichtlich funktioniert. Was ich allerdings dazu alles brauche, ist mir noch nicht klar.

Zum genannten Problem kann ich derzeit noch keine echte Lösung anbieten, erinnere mich aber natürlich an DD-WRT, bei dem ich dieses Problem in ähnlicher Weise hatte. Dazu gibt es, denke ich, zwei Lösungsansätze: a) Du definierst ja ein Gerät/Device "tun" mit der Einstellung. Das heißt, Du musst es noch bridgen. In DD-WRT war das "br0", auf den alle Geräte gemappt waren. Allerdings war auch dann erst der Traffic über den OpenVPN-Client möglich, wenn man b) unter Administrator/Diagnose in DD-WRT die Firewall konfigurierte, also verklickerte, dass br0<>tun auch uneingeschränkt routen durften.

Ob und wie man das in der Fritz umsetzen kann und muss, weiß ich an dieser Stelle natürlich noch nicht. Es ist nur ein Lösungsansatz und wenn es darin verborgen liegt, hast Du einen Vorsprung und kannst was basteln. Dadurch finde ich dann vielleicht deine Lösung hier, wenn ich das gleiche Problem haben werde. ;)
 
Hat denn wirklich keiner ne Fritte als openVPN-Client?!
Hi pascalts,

versuche seit einiger Zeit gleiches zu tun, also OpenVPN so zu konfigurieren, dass die FritzBox quasi immer eine Verbindung zu meinem VPN-Provider (IPVanish) aufbaut und hält und jeden Datenverkehr aller Clients (LAN/WLAN) so umleitet.

Was auf meinem Debian-Laptop, RasPi, Windows10-Kiste und jedem 10Euro-OpenWRT Router klappt läuft irgendwie nicht in Freetz.
Die fertigen .conf von IPVanish lassen sich ja so nicht einfach in der Freetz nutzen... (bsp. anbei)

Vielleicht hast es zwischenzeitlich geschafft und möchtest dein Ergebnis hier teilen!?
Danke & Gruß
SB
 

Anhänge

Du musst angemeldet sein, um die Anhangsliste zu sehen.
Hat denn wirklich keiner ne Fritte als openVPN-Client?!

Ich hatte diese Tage wieder mal Zeit mich mit dieser Problematik zu beschäftigen. Da meine Kenntnisse hier eher begrenzt als professionell sind, bin ich auf unüberbrückbare Hürden gestoßen.

Im Grunde scheint es gar nicht so schwer zu sein sich mit seinem VPN-Provider via OpenVPN in der Freetz zu verbinden. Ich hatte erst herausfinden müssen wo ich ein bestimmtes CERT einfügen musste, weil Freetz da nicht die gängige Bezeichnung verwendet. Auch muss SHA1 bei mir angegeben sein. Musste ich auch erst herausfinden. Dann aber klappte die Verbindung zu meinem VPN-Provider perfekt. Was ich aber nur durch das unabhängiges Netz meines iPhone sehen konnten, denn der Traffic in der FritzBox war nach Start des OpenVPN absolut Null. Wähle ich "Clients umleiten" ab, wird OpenVPN logischerweise umgangen und der Träffic ist wieder da. Das ist aber ja nicht Sinn der Sache. Also wieder aktiviert und Traffic war wieder weg.

Ich erinnerte mich, dass in meinem ASUS mit DD-WRT die Firewall in Administrator/Diagnose entsprechend eingerichtet sein muss. Also habe ich gesucht und auf ein wenig gelesen wie man das in Freetz realisieren kann. Leider lassen sich die genannten Module aber nicht im Freetz starten, es wird die Fehlermeldung: "modprobe: module modprobe not found in modules.dep" ausgegeben. Mit anderen worden ist gar keine Möglichkeit vorgegeben/implementiert die Firewall mit entsprechenden Parametern zu umgehen, obwohl diese Tables common sind. Darum wird OpenVPN auch nie in Freetz funktionieren. Es ist wohl nur Show, damit es cool und professionell wirkt, denn Verbindung bekommt man, nur nutzen kann/darf man es nicht. Ich könnte auch gar keine Einstellungen (debug.cfg) mehr hochladen, denn seit der Aktualisierung auf die 6490_07_29_ger_freetz-ng-33030MOA_image habe ich keinen Zugriff mehr mit "root" via FTP. Ich habe in meinem FTP-Programm ein Profil, das damals auch funktionierte, denn die LOGs sind alle noch da. Hatte verschiedene Daten nach /var/flash erfolgreich kopiert. Doch kein Passwort funktioniert in genannter Firmware, weder Standard, noch mein eigenes. 'Normal' komme ich schon drauf, aber das nutzt mir wenig. Lustig dann immer die Infantilfragen der Nerds ob ich schon anders versucht habe zuzugreifen. Also mir faktisch einen Tunnel in einen Laden grabe, anstatt simpel durch die Vordertür zu gehen.

Ich habe mich nun dazu entschieden Freetz aufzugeben, weil ich den ganzen Kindergarten nicht mehr mitmachen will. Sobald etwas durchschaubar wird, wirken die Nerds mit Reaktionen dagegen, die sichern sollen, dass sie die einzigen sind und bleiben, die das alles verstehen; damit man auch schön weiter freigiebig bleiben muss, denn nur mit deren Hilfe klappt ja alles. Für solch ein Kasperletheater fehlt mir der Sinn. Da sehe ich fortan lieber zu wie Farbe trocknet.
 
mit WinSCP kann man doch immer als root auf die Box zugreifen. Die WireGuardlösung wirds in 7.50 geben. (z.Z. in Beta schon da). evtl. hilft es einem weiter:
 
Zuletzt bearbeitet:
Zurück
Oben