Blockiert FritzBox OpenVPN Verbindung?
Hallo Zusammen,
wir nutzen einen kleinen Raspberry PI als OpenVPN Server hinter einer FritzBox. Es lief seit Monaten einwandfrei.
Seit einiger Zeit scheint aber die FritzBox "Daheim" oder im Büro die OpenVPN Verbindungen zu blockieren.
Nach einem Neustart der FB "Daheim" geht es wieder, umgekehrt aber auch nach einem Neustart der FB im Büro.
Hat jemand zufällig das gleiche Problem oder eine Idee wie man der Ursache finden könnte? Es ist auch auf
allen Clients (Windows, Mac, Tablet) das gleiche Problem. Auch egal ob Tunnelblick oder OpenVPN Connect.
Einzig der Reboot der FritzBox im Büro bzw. Daheim hilft...
Die einzige Fehlermeldung in Tunnelblick bzw. OpenVON Connect ist, dass das Netzwerk nicht erreichbar ist.
Aber ein Ping der Büro FB (feste IP) funktioniert und ist erreichbar.
Die FritzBoxen haben auch unterschiedlichen IP Kreis, Portweiterleitung in der Büro FB ist eingerichtet etc.
Denke, dass es eher an der FB im Büro liegt, denn auch eine Verbindung über mobilen HotSpot geht nicht
und nach Neustart der FB im Büro läuft es wieder.
Vielleicht hat jemand eine Idee, bin leider Ratlos.
VG Christian
wir nutzen einen kleinen Raspberry PI als OpenVPN Server hinter einer FritzBox. Es lief seit Monaten einwandfrei.
Seit einiger Zeit scheint aber die FritzBox "Daheim" oder im Büro die OpenVPN Verbindungen zu blockieren.
Nach einem Neustart der FB "Daheim" geht es wieder, umgekehrt aber auch nach einem Neustart der FB im Büro.
Hat jemand zufällig das gleiche Problem oder eine Idee wie man der Ursache finden könnte? Es ist auch auf
allen Clients (Windows, Mac, Tablet) das gleiche Problem. Auch egal ob Tunnelblick oder OpenVPN Connect.
Einzig der Reboot der FritzBox im Büro bzw. Daheim hilft...
Die einzige Fehlermeldung in Tunnelblick bzw. OpenVON Connect ist, dass das Netzwerk nicht erreichbar ist.
Aber ein Ping der Büro FB (feste IP) funktioniert und ist erreichbar.
Die FritzBoxen haben auch unterschiedlichen IP Kreis, Portweiterleitung in der Büro FB ist eingerichtet etc.
Denke, dass es eher an der FB im Büro liegt, denn auch eine Verbindung über mobilen HotSpot geht nicht
und nach Neustart der FB im Büro läuft es wieder.
Vielleicht hat jemand eine Idee, bin leider Ratlos.
VG Christian
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1198011512
Url: https://administrator.de/forum/blockiert-fritzbox-openvpn-verbindung-1198011512.html
Ausgedruckt am: 26.12.2024 um 14:12 Uhr
12 Kommentare
Neuester Kommentar
Alles was es zum Thema OpenVPN zu beachten gibt steht im hiesigen OpenVPN Tutorial:
Merkzettel: VPN Installation mit OpenVPN
Hat man das alles richtig umgesetzt, hat man VPN-technisch alles richtig gemacht !
Leider machst du zu deiner Installation keinerlei Angaben was eine zielführende Hilfe sehr schwer macht ohn raten zu müssen.
Das Verhalten muss dann also andere Ursachen haben. Leider bist du sehr oberflächlich mit der genauen Beschreibung, denn es wäre hier wichtig zu wissen WIE die Zielserver IP Adressierung der Clients aussieht. Ob mit statischer IP, Hostnamen bzw. DynDNS Hostnamen.
Diese zielt ja immer auf die IP Adresse der FritzBox. Hier ist es nun essentiell zu wissen ob das ein üblicher Consumer Anschluss mit xDSL Zwangstrennung und Neuvergabe der WAN IP ist.
Wenn dem so ist verliert der VPN Tunnel die Connectivity und es braucht auch etwas Zeit damit der DnyDNS das neu lernt.
Ggf. liegt auch ein Fehler der DynDNS Implementation vor das der nach Zwangstrennung die neue IP gar nicht reportet und erst nach dem Reboot nur einmalig die neue IP an den DynDNS Dienst meldet.
Leider hast du dazu ebenso keinerlei Tests und weiterführende Angaben gemacht ob das überprüft wurde. Folglich bleibt uns dann mal wieder nur die Kristallkugel.
Merkzettel: VPN Installation mit OpenVPN
Hat man das alles richtig umgesetzt, hat man VPN-technisch alles richtig gemacht !
Leider machst du zu deiner Installation keinerlei Angaben was eine zielführende Hilfe sehr schwer macht ohn raten zu müssen.
Das Verhalten muss dann also andere Ursachen haben. Leider bist du sehr oberflächlich mit der genauen Beschreibung, denn es wäre hier wichtig zu wissen WIE die Zielserver IP Adressierung der Clients aussieht. Ob mit statischer IP, Hostnamen bzw. DynDNS Hostnamen.
Diese zielt ja immer auf die IP Adresse der FritzBox. Hier ist es nun essentiell zu wissen ob das ein üblicher Consumer Anschluss mit xDSL Zwangstrennung und Neuvergabe der WAN IP ist.
Wenn dem so ist verliert der VPN Tunnel die Connectivity und es braucht auch etwas Zeit damit der DnyDNS das neu lernt.
Ggf. liegt auch ein Fehler der DynDNS Implementation vor das der nach Zwangstrennung die neue IP gar nicht reportet und erst nach dem Reboot nur einmalig die neue IP an den DynDNS Dienst meldet.
Leider hast du dazu ebenso keinerlei Tests und weiterführende Angaben gemacht ob das überprüft wurde. Folglich bleibt uns dann mal wieder nur die Kristallkugel.
weshalb es Monate lang einwandfrei lief und nun sporadisch nicht mehr geht.
Das wäre dann in der Tat etwas unverständlich, denn das passt dann nicht wirklich zum Fehlerbild. Mit einer festen IP usw. entfallen dann auch die ganzen DynDNS Problematiken.Da liegt es dann eher nahe an einen Defekt der FritzBox zu denken. Entweder Firmware oder physischer Defekt.
Firmware solltest du auf dem allerneuesten Stand haben !
Hardware Achillesferse sind oft interne Elkos in der FB die altern:
https://www.heise.de/ct/hotline/Fritzbox-durch-Elko-Tausch-wiederbeleben ...
Aber Hardware kann man über ein Forum natürlich schlecht bis gar nicht troubleshooten.
Fakt für ein richiges OpenVPN IP Adressdesign ist aber das du zwingend auf der FritzBox eine statische Route für das interne OpenVPN IP Netz anlegen musst. Andernfalls kann man mit den Clients rein nur auf dem OpenVPN Server selber arbeiten, niemals aber andere Geräte wie Drucker usw. im lokalen LAN erreichen. Das und das Aktivieren von IPv4 Forwarding im OpenVPN Server ist also immer zwingend für ein sauberes OpenVPN Design !
Ja, du hast vermutlich fälschlicherweise Masquerading (NAT bzw. IP Adress Translation) auf dem OpenVPN Server installiert.
Das passiert wenn man einem OpenVPN Tutorial folgt was für einen öffentlichen VPN Server geschrieben wurde aber nicht für einen privaten bzw. einem im Privatnetz.
NAT ist in einem privaten Netz natürlich Unsinn und kostet überflüssige Performance. In sofern ist es kontraproduktiv und keine gute Idee dort NAT zu aktivieren, denn damit schafft man sich zusätzliche eine überflüssige Hürde mit der dann aktiven NAT Firewall die IP Routimng nur in eine Richtung erlaubt. In einem privaten VPN sollte man also in jedem Falle NAT aus den iptables entfernen ! Das hiesige Tutorial weist auch darauf hin.
Dadurch das es nach einem Reboot des Routers der mit dem VPN eigentlich rein gar nichts zu tun hat wieder funktioniert widerspricht aber etwas dieser Annahme. So oder so ist Masquerading aber immer ein NoGo bei lokalen OpenVPN Installationen.
Der o.a. tls-crypt Error weist zudem auf eine fehlerhafte OpenVPN Client Konfig hin, denn dort fehlt eine entsprechende TLS Datei. Siehe dazu auch:
https://forums.openvpn.net/viewtopic.php?f=4&t=30882
Es gibt zig Posts zu dem Fehler wenn man danach sucht. Ohne deine spezifischen Konfig Dateien zu kennen ist eine zielführende Hilfe schwer möglich. Halte dich im Zweifel an das hiesige OpenVPN Tutorial was entsprechende Beispiele aufführt.
Das passiert wenn man einem OpenVPN Tutorial folgt was für einen öffentlichen VPN Server geschrieben wurde aber nicht für einen privaten bzw. einem im Privatnetz.
NAT ist in einem privaten Netz natürlich Unsinn und kostet überflüssige Performance. In sofern ist es kontraproduktiv und keine gute Idee dort NAT zu aktivieren, denn damit schafft man sich zusätzliche eine überflüssige Hürde mit der dann aktiven NAT Firewall die IP Routimng nur in eine Richtung erlaubt. In einem privaten VPN sollte man also in jedem Falle NAT aus den iptables entfernen ! Das hiesige Tutorial weist auch darauf hin.
Dadurch das es nach einem Reboot des Routers der mit dem VPN eigentlich rein gar nichts zu tun hat wieder funktioniert widerspricht aber etwas dieser Annahme. So oder so ist Masquerading aber immer ein NoGo bei lokalen OpenVPN Installationen.
Der o.a. tls-crypt Error weist zudem auf eine fehlerhafte OpenVPN Client Konfig hin, denn dort fehlt eine entsprechende TLS Datei. Siehe dazu auch:
https://forums.openvpn.net/viewtopic.php?f=4&t=30882
Es gibt zig Posts zu dem Fehler wenn man danach sucht. Ohne deine spezifischen Konfig Dateien zu kennen ist eine zielführende Hilfe schwer möglich. Halte dich im Zweifel an das hiesige OpenVPN Tutorial was entsprechende Beispiele aufführt.
Zitat von @aqui:
NAT ist in einem privaten Netz natürlich Unsinn und kostet überflüssige Performance. In sofern ist es kontraproduktiv und keine gute Idee dort NAT zu aktivieren, denn damit schafft man sich zusätzliche eine überflüssige Hürde mit der dann aktiven NAT Firewall die IP Routimng nur in eine Richtung erlaubt.
NAT ist in einem privaten Netz natürlich Unsinn und kostet überflüssige Performance. In sofern ist es kontraproduktiv und keine gute Idee dort NAT zu aktivieren, denn damit schafft man sich zusätzliche eine überflüssige Hürde mit der dann aktiven NAT Firewall die IP Routimng nur in eine Richtung erlaubt.
Ich widerspreche Dir total ungern . Wir hatten das aber letztens schon mal. Bei einem (wie hier) private to office Setup ist NAT durchaus erwünscht, denn man möchte ja nicht unbedingt, dass die Kollegen vom Office auch ins private Netz reinschnüffeln können. Gefühlt 99 % der OVPN-Anleitungen sind auch nur für eine Richtung ausgelegt.
@christian295: Ich teile @aquis Einschätzung, dass das von Dir geschilderte Fehlerbild zunächst nach einem Hardwareproblem mit (einer) der Fritzboxen klingt (wie von Dir ja auch vermutet). Die paar Fritzboxen, bei denen ich bislang nicht nachvollziehbare Probleme hatte, krankten - stets - am Netzteil. Offenbar sind Spannungsschwankungen o.ä. bei den Fritzboxen nicht so gern gesehen. Wenn Du vielleicht noch ein Netzteil hast, das passt, wäre das ein Anfang.
ABER: Da Du das Problem offenbar mit Neustart nur einer der beiden Fritzboxen, egal welcher, lösen kannst (und die sich ja nicht direkt connecten), passt Hardwareproblem einer Box wieder doch nicht zum Fehlerbild und dass beide gleichzeitig defekt sind, ist sehr unwahrscheinlich.
Deshalb würde ich den Ansatz der fehlerhaften Verbindung (TLS-Fehler) weiter verfolgen. Kurzer Google-Check sagt mir, dass entweder ein falscher (veralteter?) Client oder eine falsche (veraltete) Konfig benutzt wird. Erstaunlich ist aber auch hier, dass Du damit überhaupt eine Verbindung bekommst. Fleißig lesen dazu klärt aber meist alle Fragen. Wenn die Installation aber schon älter ist, würde ich mich damit nicht aufhalten und lieber aktualisiert bauen.
Jedenfalls würde ich die OVPN-Logs auf weitere Fehlermeldungen und Disconnects untersuchen, ebenso die Fritzbox-Logs, das mag schon zur weiteren Klärung beitragen.
Ansonsten kann natürlich auch ein fehlerhaft gebautes Netz oder ein anderes kaputtes Netzwerkgerät Störungen auslösen, die dann nach Neustart der Fritzbox (und Neuvergabe aller DHCP-Leases) erstmal behoben scheinen.
Wenn Du trotz sauberem OVPN und funktionierendem Netz immer noch sagst, das Problem ist da und nach Neustart läuft es wieder, wäre die nächste Frage, wie lange? Und das doppelt:
a) wie lange kannst Du dann die Verbindung halten? Kurzfristig oder dauerhaft und
b) kannst Du Dich nach Trennung des VPN und 6 bzw. 35 Minuten Pause wieder einwählen?
Good Luck und
Viele Grüße, commodity
Wir hatten das aber letztens schon mal.
Du hast natürlich recht ! In so einem Firmendesign mit remotem Zugriff kann das aus den o.a. Gründen durchaus absolut sinnvoll sein, keine Frage. Man muss sich aber dann immer vor Augen führen das das eine routingtechnische Einbahnstrasse ist. Gut, zumindestens bei einem Site-to-Site Design. Bei einem Client-to-Site Design ist das sicher weniger relevant.Danke für den Hinweis ! Für's nächte Mal hab ich das auf dem Radar ! 😉
Das tut er sicher nur weil er Lancom Händler ist und Provision bekommt... Ein Schelm wer Böses dabei denkt.
Im Ernst... Diese simple Anforderung schafft auch jede beliebige andere VPN Hardware.
Einfacher, schneller und preiswerter wäre das für dich es mit einer Router Kaskade zu lösen wobei der hinter der FB kaskadierte Router dann OpenVPN Server spielt.
Mit einem 50 Euro Mikrotik_hEX z.B. ist das schnell und preiswert im Handumdrehen erledigt.
Clientverbindung OpenVPN Mikrotik
Merkzettel: VPN Installation mit OpenVPN
Im Ernst... Diese simple Anforderung schafft auch jede beliebige andere VPN Hardware.
Einfacher, schneller und preiswerter wäre das für dich es mit einer Router Kaskade zu lösen wobei der hinter der FB kaskadierte Router dann OpenVPN Server spielt.
Mit einem 50 Euro Mikrotik_hEX z.B. ist das schnell und preiswert im Handumdrehen erledigt.
Clientverbindung OpenVPN Mikrotik
Merkzettel: VPN Installation mit OpenVPN
Viele Dienstleister stecken heute lieber Bauteile ins Netz als selbst mal Hand anzulegen. Ob sie das machen, weil sie damit Geld verdienen? Oft habe ich das Gefühl, sie können das andere gar nicht mehr. Ist jedenfalls schnelleres Geld, da geb ich @aqui vollauf recht.
Mach es selbst mit einer neuen Installation (alte SD-Karte kannste ja erstmal behalten): https://ctaas.de/OpenVPN_Server_Ubuntu_howto.htm
oder folge @aqui, nimm den kleinen hEX. Oder koppele die beiden Fritzboxen, geht ja auch ganz einfach.
Viele Grüße, commodity
Mach es selbst mit einer neuen Installation (alte SD-Karte kannste ja erstmal behalten): https://ctaas.de/OpenVPN_Server_Ubuntu_howto.htm
oder folge @aqui, nimm den kleinen hEX. Oder koppele die beiden Fritzboxen, geht ja auch ganz einfach.
Viele Grüße, commodity
Ich habe das gleiche Problem und schon zahlreiche VPN (und Netzwerke...) installiert.
Es liegt eindeutig and der Fritzbox Konfiguration. Das Problem konnte ich zwar noch nicht lösen.
@christian295 hast du eine Lösung gefunden?
Es liegt eindeutig and der Fritzbox Konfiguration. Das Problem konnte ich zwar noch nicht lösen.
@christian295 hast du eine Lösung gefunden?