Kein Zugriff aus internem Netz auf NC / DNS-Rebind-Schutz in der AVM Fritz!Box?

dtb · December 28, 2021, 9:12am

Hallo User,

leider muss ich mich schon wieder einmal melden. In einem anderen Thread hatte ich vor kurzem das Problem mit “trusted_domains” aus der config.php. Dies hatte sich ohne mein Zutun von selber gelöst. Nun habe ich folgenden neuen Effekt:

Mein Zugriff auf die NC, ich nutze NextCloud Pi, geht nur noch vollständig aus dem öffentlichen Netz heraus, intern geht es zeitweise nur über eine Zertifikatsausnahmeregelung (Let’s Encrypt), teilweise erhält man nur den Hinweis auf ein Verbindungsproblem.

Meine Clients auf den lokalen Geräten synchronisieren seither nicht mehr, Handys dito. Sobald man ins öffentliche Netz (Mobilfunk) wechselt, ist alles ok.

Ich vermute immer noch, es hängt an den Einträgen vom “trusted_domains” in der config.php. Diese Änderungen werden bei Aktualisierung des Zertifikates von Let’s Encrypt vorgenommen. Hier mal der aktuelle Inhalt:

'trusted_domains' => 
  array (
    0 => 'localhost',
    1 => 'INTERNE IP',
    2 => 'EXTERNE URL',
    11 => 'EXTERNE IP',
    3 => 'EXTERNE URL',
  ),

Die externe URL und interne IP habe ich nicht im Klartext hier angegeben. Allein die vielen doppelten Einträge sind doch schon ein Hinweis auf ein Problem.

Über das WebUI (Admin) hat man über “nc-trusted_domains” auch 3 Domains manuell einzutragen. Die Felder sind aber leer. Im error_log fand ich noch folgenden Eintrag:

[ssl:error] [pid 904:tid 547965781376] AH02604: Unable to configure certificate localhost:4443:0 for stapling

Das Zertifikat von LetsEncrypt habe ich auch manuell über die WebUI Schnittstelle erneuert, dies verlief ohne Probleme, die Gültigkeit ist bis Mai2022. Daran kann es auch nicht liegen.

Was meint Ihr, wo ist der Fehler?

Thomas

dtb · December 29, 2021, 8:57am

Guten Morgen, ich habe kleine Neuigkeiten,

aus einem mir unerklärlichen Grund funktioniert heute plötzlich der Zugriff aus dem lokalen LAN wieder. An den Einträgen in der config.php zu “trusted_domains” hat sich nichts geändert.

Jetzt kommt aber wieder eine " Sicherheits- & Einrichtungswarnung" unter Einstellungen/Übersicht:

Die Reverse-Proxy-Header-Konfiguration ist fehlerhaft oder Du greifst auf Nextcloud über einen vertrauenswürdigen Proxy zu. Ist dies nicht der Fall, dann besteht ein Sicherheitsproblem, das einem Angreifer erlaubt, die IP-Adresse, die für Nextcloud sichtbar ist, auszuspähen. Weitere Informationen hierzu finden sich in der [Dokumentation ↗](https://docs.nextcloud.com/server/22/go.php?to=admin-reverse-proxy).

Nach Recherchen komme ich wieder zur config.php und dem Eintrag:

trusted_proxies

In meiner config.php steht dazu:

'trusted_proxies' => 
  array (
    11 => '127.0.0.1',
    12 => '::1',
    13 => 'EXTERNE URL',
    14 => 'EXTERNE IP',
  ),

Aus der Dokumentation werde ich nicht schlau. Kann der Proxy die FritzBox 7390 sein? Vielfach findet man den Hinweis den internen Adressbereich vom lokalen LAN noch anzugeben. Dann müsste ich noch folgendes ergänzen:

'trusted_proxies' => 
  array (
    0 => 'INTERNE IP der NC/8',
    11 => '127.0.0.1',
    12 => '::1',
    13 => 'EXTERNE URL',
    14 => 'EXTERNE IP',
  ),

oder nur:

'trusted_proxies' => 'INETRENE IP der NC/8',

Ich möchte nicht experimentieren und erst hier fragen. Was meint Ihr?

Thomas

dtb · December 29, 2021, 4:11pm

Guten Abend,

ich habe weiter mit den Einträgen im trusted_proxies versucht der Ursache näherzukommen. Leider ohne Erfolg, auf keine Änderung (siehe vorher) hat die NC reagiert.

Interessant wäre noch zu erwähnen, dass am Vormittag die NC im lokalen LAN lief, ohne Änderungen. Jetzt, nach ca. 6 Stunden, ohne meinen Einfluss plötzlich nicht mehr.

Was kann das nur sein? Hat jemand eine Idee?

Thomas

devnull · December 30, 2021, 9:55am

Ich verstehe nicht, warum du nicht einfach immer und überall die weltweite Adresse inkl. deines Lets Encrypt-Zertifikats nutzt. Such vielleicht mal nach Hairpinning und NAT Loopback

Was machst du denn mit deinem Smartphone? Du änderst dann deine Nextcloud-Android/iOS-Servereinstellungen zwischen zuhause und unterwegs? Nicht wirklich, oder?

Schmeiß mal die ganzen lokalen Adressen raus und behebe das Problem richtig. Und bitte deaktiviere IPv6 falls du nicht weißst, wofür das überhaupt gut ist.

dtb · December 30, 2021, 10:41am

Hallo @devnull,

danke für Deine Antwort zu meinem Problem. Ich habe bei allen Geräten in den Clients die EXTERNE IP oder den Domainnamen zur Authentifizierung eingetragen. Dies lief stabil über ein Jahr bis vor ca. 2 Monaten als die “Sicherheits- & Einrichtungswarnung” (siehe oben) erschien. Der erste Ansatz diesbezüglich war trusted_domains aus der config.sys. Nach 2 Wochen verlief sich das Problem ohne irgendwelche Änderungen und lief bis vor wendigen Tagen ausgezeichnet. Jetzt erscheint wieder die “Sicherheits- & Einrichtungswarnung” und ein Zugriff aus dem lokalen LAN ist nicht mehr möglich. Bei dem Problem vor zwei Monaten ging dies aber. Paradox ist auch, dass es Zeiten (Stunden) gibt, wo alles funktioniert (so jetzt gerade) und dann plötzlich nicht mehr.

Einen Wechsel zw. internen und externen Adressen auf den Clients kann ich umgehen, indem ich einfach das WLAN auf den Clients deaktiviere und somit über 4G arbeite. Dies kann aber auch keine Dauerlösung werden! Mit dem PC nutze ich zu 99% aus dem WLAN heraus die Synchronisation aller meiner Daten und NC Talk. Über 4G wäre dies wenig sinnvoll.

Kannst Du mir bitte Deinen Hinweis:

Schmeiß mal die ganzen lokalen Adressen raus und behebe das Problem richtig. Und bitte deaktiviere IPv6 falls du nicht weißst, wofür das überhaupt gut ist.

näher untersetzen? IPv6 ist in der Fritz!Box 7390 deaktiviert, bzw. nicht aktiviert. Du meinst ev. auf der NextCloud? Wenn ja, wie?
Mit den lokalen Adressen meinst Du die im Array von trusted_proxies?

Gern würde ich mit Dir das Problem richtig beheben. Ich muss bald für einige Wochen weg, da sollte die NC zu 100% funktionieren.

Vielen Dank.

Thomas

wwe · December 30, 2021, 9:37pm

hallo Thomas,

'trusted_proxies'

hat nichts mit der internen/externen IP der Nextcloud zu tun

lese dir diesen Thread und die Links durch

vermutlich hilft dir das Problem zu verstehen und die Konfig zu korrigieren… sinnvolle Suchbegriffe in diesem Forum: rebind protection, local LAN, dns split-brain

dtb · December 31, 2021, 10:16am

Hallo Willi,

danke für den Tipp. Ich bin diesem gefolgt und bin auch auf User mit gleichem Problem gestoßen. Im DE waren das alle USER mit einer Fritz!Box. Eine Lösung bestand im DNS Eintrag der NC, wo man gern die Fritz!Box einträgt und besser den google nehmen sollte. Bei mir hat dies aber nichts gebracht. Vielfach vermutet man das Problem im Router (Fritz!Box) unter NAT. Interessant ist auch, dass häufig der NC Dienst “HPB Service” down sein soll. Bei mir ist es auch so!

Die config.php habe ich “überflüssige” Einträge bei trusted_proxies entfernt. Sobald aber Lets Encrypt läuft, werden diese wieder eingetragen. Im Moment gehts wieder intern nicht.

Der Prozess “rebind protection” der Fritz!Box 7390 könnte der Übeltäter sein.

Was kann ich machen bze. der Ursache näher kommen?

Thomas

bb77 · December 31, 2021, 11:01am

Hallo @dtb

Ich kann hier nur etwas allgemeiner gefasste Antwort geben, da ich NextcloudPi und auch die Fritzbox nicht im Detail kenne. Ich glaube aber nicht, dass die Probleme mit den “trusted domains” Einträgen zu tun haben und wenn nur indirekt.

Das ist subotimal. Trage am besten überall nur den externen Domainnamen ein. Alles andere sind Workarounds, die nicht das eigentliche Problem lösen. Das Ziel hier sollte sein, dass du mit allen Geräten, sowohl aus dem lokalen Netz, wie auch aus dem Internet ausschliesslich via Domainnamen, sprich “EXTERNE_URL” auf deine Nextcloud zugreifen kannst.

Vergiss mal efür einen Moment die Trusted Proxies. Dort muss genau ein Eintrag drinn sein, und zwar deine “externe” URL. Wenn DNS intern und extern funzt, bzw. NAT Loopback richtig funktioniert, braucht es die anderen Einträge nicht, sie stören aber auch erstmal nicht weiter.

Folgende Punkte müssen erfüllt sein, dass es so wie oben gesagt funktioniert.

Port 80 und 443 müssen in der Fritzbox via Portforwarding an den Nextcloud Server weitergeleitet werden. Deaktiviere am besten alle “MyFritz”-Shenanigans, die irgendwie das WebUI der FritzBox von aussen erreichbar machen oder dich sonst mit irgendwelcher “Magie” unterstützen wollen. Das tun sie nämlich in diesem Fall nicht. Im Gegenteil, sie bieten Konfliktpotential mit dem Portforwarding, wenn sie auch Port 80 und/oder 443 nutzen wollen.
Damit NAT-Loopback funktioniert, muss muss eine Ausnahme im DNS-Rebind Schutz der Fritzbox definiert werde, so dass bei DNS Anfragen für “cloud.deinedomain.de”, welche dem Client ja deine externe IP Adresse zurückgibt, der Traffic in der Fritzbox wieder zurück in dein LAN, zum Raspi geroutet wird. DNS-Auflösung privater IP-Adressen nicht möglich | FRITZ!Box 7362 SL | AVM Deutschland. Auch hier nochmal: Irgendwelche Automagie der Fritzbox könnte hier stören.

Eine weitere, zwar aufwändigere, aber imho auch sauberere und in der Regel auch performantere Lösung, wäre einen seperaten internen DNS Server zu verwenden, auf welchem du dann einen lokalen “host override” für “cloud.deinedomain.de” setzt. Dann wird bei DNS Anfragen im internen Netz die lokale IP Adresse deine Pis zurücggeben, anstatt die externe IP Adresse.

dtb · December 31, 2021, 11:48am

Hallo @bb77,

Deinen Erklärungen kann ich gut folgen. Mittlerweile war ich schon selber durch die Recherchen auf den rebind Schutz (NAT Loopback) der Fritz!Box gekommen und habe in der 7390 auch den FQDN hinterlegt. Auch nach mehreren Neustarts der Fritz!Box hat der Eintrag keinen Einfluss. Ein Ping geht immer an die externe IT der Fritz!Box. Testhalter habe ich den DNS mit dem FQDN über die hosts Datei von Windows aufgelöst. Damit war alles ok, jeglicher Dienst ist auch gelaufen und war erreichbar. Der Ping geht dann auch an die interne IP der NC.

Scheinbar setzt die Fritz!Box den Eintrag nicht so um, wie sie es sollte.

Neue FB? Hat man da eine Garantie auf Funktion? Die Firmware der 7390 ist Anfang Dezember 2021 automatisch geupdatet. Das kommt zeitlich mit dem Auftreten des Problems hin.

Was kann ich noch machen?

Thomas

bb77 · December 31, 2021, 12:15pm

Dann scheint NAT Loopback / Hairpin NAT / NAT Reflection, aus iregndeinem Grund nicht zu funktionieren, buggy zu sein in der aktuellen Firmware, oder eventuell gar nicht mehr unterstützt zu sein? Letzteres glaube ich zwar eher nicht. Eventuell muss man es irgendwo in den Einstellungen aktivieren? Oder irgendeine andere Einstellung oder ein anderer Dienst / Automatismus auf der Fritzbox spielt da noch mit rein…? Nutzt du den MyFritz DynDNS Dienst, oder einen anderen?

Eventuell mal bei AVM direkt nachfragen…

…oder einen eigenen DNS-Server betreiben. Ich kann da z.B. Pi-hole empfehlen, und quasi als Bonus, gibt es damit noch einen netzwerkweiten Werbeblocker mit dazu

dtb · December 31, 2021, 2:02pm

Hallo @bb77,

AVM hat für dieses Produkt den Support eingestellt und verweist nur noch auf die Wissensdatenbank. Am 09.12.2021 war das letzte Update und seither habe ich diese Schwierigkeiten. Zu anderen Modellen findet man auch nicht viel, meist nur die Erklärung zur Einrichtung. Bleibt nur ein neueres Modell, eine 7560 liegt noch im Schrank. Ich wehre mich aber noch…der Aufwand…beim Provider muss ich dies melden…also nicht schnell man zurück zubauen… Gab es nicht mal eine alternative Firmware?

Thomas

bb77 · December 31, 2021, 2:34pm

Bevor du dieses “Rabbit hole” runtergehst, schau dir doch mal Pi-hole an. NAT Loopback ist imho sowieso nur eine “Notlösung”, die oft auch deutlich schlechter performt, als wenn der Traffic direkt zum Server geht.

Anderseits könntest du natürlich mit einer alternativen Firmware wie OpenWRT dann auch DNS auf deinem Router machen, oder anders gesagt: Viele Wege führen nach Rom und zu interner DNS-Auflösung. Die Frage ist, wieviel Aufwand du betreiben willst, im Sinne von “Basteln” und “hacken” und wieviel Wissen über Netzwerke, Firewalls, Router etc… du hast oder dir aneignen willst. OpenWRT, wenn es denn auf der Fritz läuft, erfordert schon etwas mehr Aufwand und Wissen als FitzOS. Auch bietet es auf vielen Routermodellen keine Hardwarebeschleunigung (war zumindest früher so), was dann den Durchsatz verringern kann.

Pi-hole wäre der einfache Weg. Und das läuft auch auf älteren Raspis mit 512MB. Sowas hat man evtl. sogar noch irgendwo rumliegen…?

dtb · December 31, 2021, 4:05pm

@bb77

Ein Raspi liegt bei mir auch immer rum, jedoch möchte ich keinen zusätzlichen aufstellen. Ich bin häufig für Wochen unterwegs und da ist jedes Gerät was läuft ein Risiko. Ich muss dies anders in den Griff bekommen! Ich habe x-mal den Domainnamen in der Fritz!Box im Feld DNS-Rebind-Schutz ein- und ausgetragen, jedes mal neu gestartet. Und nun…jetzt verbindet sich mein NB mit der NC plötzlich. Warum kann ich nicht nachvollziehen! Diesen Effekt hatte ich aber schon häufiger, mal gehts, mal gehts nicht. Werde die Fritz!Box nochmal neu starten und wenn sich der NB wieder verbindet, belasse ich es dabei bis zum nächsten Ausfall.

Thomas

dtb · January 1, 2022, 8:46am

Hallo @devnull, hallo @wwe und hallo @bb77,

ich wünsche Euch ein erfolgreiches, glückliches und gesundes Neues Jahr 2022. Ich sollte auch zufrieden sein, meine NC läuft seit gestern ohne nennenswerte Probleme. Die Sicherheitswarnung (siehe oben) wird zwar wieder ausgegeben, aber dafür haben alle Geräte im lokalen LAN wieder Zugriff.

Das Problem ist, bzw. war, der “DNS-Rebind-Schutz” in meiner Fritz!Box. Obwohl ich die Domain eingetragen habe, wurde diese nicht berücksichtigt. Nach gefühlten 100 Neustarts der Fritz!Box war alles ok, ich hatte nur den Eintrag raus, wieder rein und das Verhalten geprüft. Anscheinend hat sich die “alte” 7390 für 2022 den Vorsatz gegeben zu FUNKTIONIEREN.

Vielen Dank nochmal für Eure Unterstützung. Sollte die Box den Vorsatz doch wieder aufgeben, melde ich mich.

Thomas

bb77 · January 1, 2022, 10:32am

Schön zu hören, dass es doch noch geklappt hat.

Wünsche dir auch alles Gute für das neue Jahr.

devnull · January 2, 2022, 7:40am

@dtb
Auch wenn dein Problem scheinbar behoben wurde, wollte ich zu der oben aufgeführten Aussage noch was schreiben. Es ist meiner Meinung nach normal, dass im internen Nertzwerk für die Nextcloud-Adresse dann auch die externe IP der Fritzbox aufgelöst wird. Vielleicht kannst du das auch noch mal verifizieren. Denn das ist natürlich das Prinzip von NAT-Loopback.
Bei mir ist es z. B. so, dass ich für meine interne Nextcloud einen DynDNS-Namen und darauf einen CNAME meiner eigener Domain verwende. Bei beiden handelt es sich natürlich um weltweite IPv4-Adressen, die zu jedem Zeitpunkt die weltweite IP-Adresse meiner Fritzbox und nicht irgendeine interne IP-Adresse darstellen. Und das gilt von außen wie von innen.

dtb · January 2, 2022, 8:17am

Hallo @devnull,

wenn ich von intern den Domainnamen anpinge, löst die Fritz!Box auf die externe IP auf. Dies kann sie nur, wenn ein DNS beteiligt war. Bedeutet aber auch, die Fritz!Box muss beim Aufruf der NC mittels Domainnamen erkennen, dass:

der Aufruf von intern erfolgte,
der Domainname im “DNS-Rebind-Schutz” steht

und damit die interne Anfrage über die Freigaben zur richtigen internen IT auflöst. Also alle IP Pakete über die externe WAN Schnittstelle schleust. Oder?

Thomas

devnull · January 2, 2022, 10:28am

Du bekommst die externe IP für den (extrenen) Namen, da der Name ja auch irgendwo extern definiert wurde. Deine Fritzbox fragt hierfür auch nur andere Nameserver bzw. im ersten Schritt erst mal den Nameserver deines Internet-Providers.

Es ist eher so, dass die Fritzbox erkennt, dass die von innen zu erreichende externe Adresse der Fritzbox eine Umleitung zu einer internen Adresse ist und somit die Fritzbox das intern korrekt umsetzt. Daher wohl NAT Loopback. Eine Art NAT zurück ins eigene Netzwerk.

Client (intern) -> Fritzbox (externe IP für Nextcloud) -> Nextcloud (intern IP)

Du könntest mal ein traceroute (Linux Client) oder tracert (Windows Client) machen.

traceroute nextcloud-externer-name
tracert nextcloud-externer-name

bb77 · January 2, 2022, 10:38am

Genau das. Der entscheidende Punkt ist aber, dass ohne NAT Reflection die Antwort vom Server direkt an den Clinet zurückgeht. Der Client erwartet aber eine Antwort von der IP an die er das Pakte gesendet hat und das ist die externe IP der Fritzbox und nicht die des Servers. Die Verbindung wird in der Folge abgelehnt.

Hier eine gute Erklärung: iptables - How does NAT reflection (NAT loopback) work? - Unix & Linux Stack Exchange

Hab das mal in den DeepL Translator geworfen und es hier reinkopiert:

Ohne NAT-Reflection:

Der Client erstellt das Ausgangspaket (tcp syn) und adressiert es an die öffentliche IP. Der Client erwartet eine Antwort auf dieses Paket mit vertauschter Quell-IP/Port und Ziel-IP/Port.

Da der Client keine spezifischen Einträge in seiner Routing-Tabelle hat, sendet er es an sein Standard-Gateway. Das Standard-Gateway ist die NAT-Box.
Die NAT-Box empfängt das ursprüngliche Paket, ändert die Ziel-IP, erstellt einen Eintrag in der Zuordnungstabelle, sucht das neue Ziel in ihrer Routing-Tabelle und sendet die Pakete an den Server. Die Quelladresse bleibt unverändert.
Der Server empfängt das Ausgangspaket und erstellt eine Antwort (syn-ack). In der Antwort wird die Quell-IP/Port mit der Ziel-IP/Port vertauscht. Da die Quell-IP des eingehenden Pakets unverändert blieb, ist die Ziel-IP der Antwort die IP des Clients.
Der Server sucht die IP in seiner Routing-Tabelle und sendet das Paket an den Client zurück.
Der Client lehnt das Paket ab, weil die Quelladresse nicht mit dem übereinstimmt, was er erwartet.

Mit NAT-Reflection:

Der Client erstellt das erste Paket (tcp syn) und adressiert es an die öffentliche IP. Der Client erwartet eine Antwort auf dieses Paket mit vertauschter Quell-IP/Port und Ziel-IP/Port.
Da der Client keine spezifischen Einträge in seinen Routing-Tabellen hat, sendet er es an sein Standard-Gateway. Das Standard-Gateway ist die NAT-Box.
Die NAT-Box empfängt das ursprüngliche Paket, ändert anhand der Einträge in der NAT-Tabelle die Ziel-IP, die Quell-IP und möglicherweise den Quell-Port (der Quell-Port wird nur geändert, wenn dies zur Eindeutigkeit erforderlich ist), erstellt einen Eintrag in der Zuordnungstabelle, sucht das neue Ziel in seiner Routing-Tabelle und sendet die Pakete an den Server.
Der Server empfängt das erste Paket und erstellt eine Antwort (syn-ack). In der Antwort wird die Quell-IP/Port mit der Ziel-IP/Port vertauscht. Da die Quell-IP des eingehenden Pakets durch die NAT-Box geändert wurde, ist die Ziel-IP des Pakets die IP der NAT-Box.
Der Server sucht die IP in seiner Routing-Tabelle und sendet das Paket zurück an die NAT-Box.
Die NAT-Box sucht die Details des Pakets (Quell-IP, Quell-Port, Ziel-IP, Ziel-Port) in ihren NAT-Mapping-Tabellen und führt eine Rückübersetzung durch. Dabei wird die Quell-IP in die öffentliche IP, der Quell-Port in 80, die Ziel-IP in die IP des Kunden und der Ziel-Port wieder in den vom Kunden verwendeten Quell-Port geändert.
Die NAT-Box sucht in ihrer Routing-Tabelle nach der neuen Ziel-IP und sendet das Paket zurück an den Client.
Der Client nimmt das Paket an.
Die Kommunikation wird fortgesetzt, wobei das NAT die Pakete hin und her übersetzt.

dtb · January 2, 2022, 4:07pm

Leider muss ich mich doch wieder melden. Nach ca. 24 Stunden ist die NC intern wieder nicht zu erreichen. File2ban habe ich auf 24 Stunden konfiguriert, nur so ein Gedanke, sollte damit doch keine Verknüpfung haben. Werde die Fritz!Box wieder mehrfach starten und warten.

Thomas