christian295
Goto Top

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

Content-ID: 1198011512

Url: https://administrator.de/contentid/1198011512

Ausgedruckt am: 22.11.2024 um 09:11 Uhr

aqui
aqui 26.08.2021 aktualisiert um 21:17:28 Uhr
Goto Top
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. face-sad
christian295
christian295 27.08.2021 um 08:47:03 Uhr
Goto Top
Guten Morgen,
du hast recht meine Informationen waren recht dürftig, sorry. Also nochmals mehr Details:

- Dieses Merkblatt kenne ich noch nicht; hatte eine andere; diese aber 1:1 umgesetzt
- wir haben einen Business Anschluss mit Fester IP, keine Zwangstrennung, kein DynDNS
- der OpenVPN Server hat eine feste "interne"
- die Portweiterleitung in der FB ist eingestellt
- an der FB ist DHCP ausgeschaltet, dies übernimmt unser Server

Dank deines Merkblatts bin ich auf die Punkte "Statische Route" sowie "IP Netz VPN Server" gestoßen,
hier bin ich nicht sicher ob das wirklich so ist bzw. in der Anleitung die ich hatte beschrieben wurde.
Das muss ich prüfen - vielleicht liegt es daran, allerdings verstehe ich dann nicht weshalb es Monate
lang einwandfrei lief und nun sporadisch nicht mehr geht.

Danke
aqui
aqui 27.08.2021 aktualisiert um 09:19:46 Uhr
Goto Top
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 !
christian295
christian295 27.08.2021 um 10:07:28 Uhr
Goto Top
Danke für Deine Antwort - Die FB ist aktuell, wie alles andere auch. Also HW Defekt möglich.

Zugriff auf die anderen Geräte wie Drucker, Server usw. klappt Problemlos - obwohl in der FB keine statische Route hinterlegt ist (habe ich schon geschaut)..?! Nur das "IP Netz (Forwarding?)" vom OpenVPN Server habe ich noch nicht geschaut.
christian295
christian295 27.08.2021 um 10:23:33 Uhr
Goto Top
ich habe jetzt mal folgendes bei "PiVPN" gefunden:

:: [OK] IP forwarding is enabled
:: [OK] Iptables MASQUERADE rule set
:: [OK] OpenVPN is running
:: [OK] OpenVPN is enabled (it will automatically start on reboot)
:: [OK] OpenVPN is listening on port 1194/udp

Dann Log:

Aug 26 10:10:42 pi-vpn ovpn-server[516]: REDACTED:65394 [USER] Peer Connection Initiated with [AF_INET]REDACTED:65394
Aug 26 10:10:42 pi-vpn ovpn-server[516]: MULTI: new connection by client 'CLIENT' will cause previous active sessions by this client to be dropped. Remember to use the --duplicate-cn option if you want multiple clients using the same certificate or username to concurrently connect.
Aug 26 10:10:42 pi-vpn ovpn-server[516]: OPTIONS IMPORT: reading client specific options from: /etc/openvpn/ccd/USER
Aug 26 10:10:42 pi-vpn ovpn-server[516]: MULTI: Learn: 10.8.0.3 -> USER/REDACTED:65394
Aug 26 10:10:42 pi-vpn ovpn-server[516]: MULTI: primary virtual IP for USER/REDACTED:65394: 10.8.0.3
Aug 26 10:10:43 pi-vpn ovpn-server[516]: USER/REDACTED:65394 PUSH: Received control message: 'PUSH_REQUEST'
Aug 26 10:10:43 pi-vpn ovpn-server[516]: USER/REDACTED:65394 SENT CONTROL [USER]: 'PUSH_REPLY,dhcp-option DNS 192.168.89.89,block-outside-dns,redirect-gateway def1,route-gateway 10.8.0.1,topology subnet,ping 15,ping-restart 120,ifconfig 10.8.0.3 255.255.255.0,peer-id 1,cipher AES-256-GCM' (status=1)
Aug 26 10:10:43 pi-vpn ovpn-server[516]: USER/REDACTED:65394 Data Channel: using negotiated cipher 'AES-256-GCM'
Aug 26 10:10:43 pi-vpn ovpn-server[516]: USER/REDACTED:65394 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Aug 26 10:10:43 pi-vpn ovpn-server[516]: USER/REDACTED:65394 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Aug 26 10:45:38 pi-vpn ovpn-server[516]: USER/REDACTED:65394 [FranziskaSavage] Inactivity timeout (--ping-restart), restarting
Aug 26 10:45:38 pi-vpn ovpn-server[516]: USER/REDACTED:65394 SIGUSR1[soft,ping-restart] received, client-instance restarting
Aug 26 23:45:18 pi-vpn ovpn-server[516]: tls-crypt unwrap error: packet too short
Aug 26 23:45:18 pi-vpn ovpn-server[516]: TLS Error: tls-crypt unwrapping failed from [AF_INET]REDACTED:51757
Aug 27 04:29:46 pi-vpn ovpn-server[516]: tls-crypt unwrap error: packet too short
Aug 27 04:29:46 pi-vpn ovpn-server[516]: TLS Error: tls-crypt unwrapping failed from [AF_INET]REDACTED:35825
Aug 27 05:21:26 pi-vpn ovpn-server[516]: tls-crypt unwrap error: packet too short
Aug 27 05:21:26 pi-vpn ovpn-server[516]: TLS Error: tls-crypt unwrapping failed from [AF_INET]REDACTED:49257
Aug 27 06:32:06 pi-vpn ovpn-server[516]: tls-crypt unwrap error: packet too short
Aug 27 06:32:06 pi-vpn ovpn-server[516]: TLS Error: tls-crypt unwrapping failed from [AF_INET]REDACTED:44310


kannst du damit etwas anfangen?
aqui
aqui 27.08.2021 aktualisiert um 10:41:03 Uhr
Goto Top
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.
commodity
commodity 28.08.2021 um 14:20:56 Uhr
Goto Top
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.

Ich widerspreche Dir total ungern face-wink. 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
aqui
aqui 28.08.2021 um 16:50:14 Uhr
Goto Top
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 ! 😉
christian295
christian295 08.09.2021 um 10:46:31 Uhr
Goto Top
Hallo Zusammen,
danke erstmal für die Antworten und sorry das ich nicht mehr geschrieben habe. Hab erstmal mit unserem IT Dienstleister gesprochen ob er das richten / konfigurieren kann, da das mein Wissen übersteigt und ich keine Zeit habe mich einzulesen gerade. Aber leider nicht bzw. nur mit Lancom Routern.. Will aber eigentlich nicht wieder was neues, der kleine Raspberry tut was er soll face-smile
Kennt ihr zufällig jemand der das Remote machen könnte? Natürlich gegen Bezahlung face-big-smile Selbst wenn sich dann rausstellt, dass die FB ne Macke hat, ist es dann zumindest ordentlich konfiguriert. Oder seit ihr auch auf der Seite meines IT Dienstleisters und würdet zu nem Lancom Router raten? LG
aqui
aqui 08.09.2021, aktualisiert am 29.12.2022 um 11:02:50 Uhr
Goto Top
Das tut er sicher nur weil er Lancom Händler ist und Provision bekommt... Ein Schelm wer Böses dabei denkt. face-wink
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
commodity
commodity 09.09.2021 aktualisiert um 22:59:43 Uhr
Goto Top
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
derand
derand 29.12.2022 um 07:56:05 Uhr
Goto Top
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?