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

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

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

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

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.

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

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

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

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. https://avm.de/service/wissensdatenbank/dok/FRITZ-Box-7362-SL/663_DNS-Auflosung-privater-IP-Adressen-nicht-moglich/. 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.

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

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 :wink:

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

Bevor du dieses “Rabbit hole” runtergehst, :wink: 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
?

@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

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. :joy:

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

Thomas

2 Likes

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

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

@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.

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:

  1. der Aufruf von intern erfolgte,
  2. 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

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

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.

1 Like

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. :thinking:

Thomas