Fritzbox 7590 leitet auf falsche Freigabe um (bei Port 443)

[rainworm]

Hi,

ich habe eine FB 7590 und folgendes Problem:

Ich habe zwei Geräte per Fritzbox-Freigabe geöffnet: A und B

Gerät A (nextcloud): Port 80 und 443 ->> Freigabe: a.myfritz.net und
Gerät B: Port 123 --> Freigabe b.myfritz.net

Jetzt habe ich das kuriose Problem od. Bug, dass sobald ich 443 auf Gerät A öffne, "b.myfritz.net" auf Gerät A umleitet (da öffnet sich bei mir das nextcloud Webinterface). Entsprechend wird auch der AAAA-Record umgebogen...Ist das so gewollt? Kann ich das ändern?

Viele Grüße
rainworm

 

[rainworm]

Kann das Problem jemand bestätigen?

 

[Theo Tintensich]

Port 123 --> Freigabe b.myfritz.net

Der Port 123 ist eine ganz doofe Idee, denn das ist der Port für NTP. Nimm einen anderen Port.

Liste der Portnummern – Wikipedia

de.wikipedia.org

zum Beispiel 122, der ist nicht spezifiziert.

 

[rainworm]

Das war ein Beispiel und ist hier auch nicht relevant. Es geht darum, wenn man Port 443 freigibt

 

[Cyberrob90]

Ich weiß, dass der Thread leider schon alt ist.
Ich habe das selbe Problem, erst seit heute.
Die FritzBox ist seit mehreren Wochen auf Firmware 7.50
Geändert habe ich NICHTS.
Das Problem ist reproduzierbar, von allen Geräten IM Netzwerk.
Leider finde ich hierfür keine Lösung.
Bist du seinerzeit weitergekommen?

Workaround ist ein manueller Eintrag in der HOSTS Datei, was dann aber natürlich bei keinem Smartphone geht.
Scheint ja ein Problem mit der FritzBox zu sein...

 

[sonyKatze]

Auch wenn Du das gleiche Symptom wie der Thread-Ersteller hast, immer gut nochmal in eigenen Worten zu schildern (denn ich verstehe nicht einmal den Thread-Ersteller). Noch toller wäre, wenn ein Dritter den Fehler aus der Beschreibung gezielt nachbauen könnte. Also, „ich habe diese Schritte ausgeführt und dann das erwartet, aber es passierte“. Wie man einen Software-Bug beschreiben sollte. Zum Beispiel was bedeutet „sobald ich 443 öffne“? Auf dem Server, in einem anderen Client, von Außen, von Innen?

Der nächste Schritt wäre, die DNS-Records (A, AAAA und CNAME) direkt über ein Programm auszulesen, also zum Beispiel unter Linux das Tool dig. Das dann sowohl innerhalb des Heimnetzes (mit FRITZ!Box als DNS-Forwarder) und innerhalb des Heimnetzes mit einem anderen DNS-Anbieter und einmal von außerhalb des Heimnetzes, zum Beispiel Mobilfunk.

 

[Cyberrob90]

Also, ich habe eine FritzBox, einen IntelNUC mit Nextcloud Instanz unter virtualisiertem Debian und mehrere Rechner im Netzwerk.
Dazu ein LetsEncrypt Zertifikat.

Also an der FritzBox eingestellt, eingehenden Datenverkehr an die IP der FritzBox (über DynDNS per URL Eingabe zuverlässig immer die aktuelle IP der Box) über Port 443 bitte an den Webserver unter Debian leiten.
Klappt 1a, von außerhalb des Heimnetzes.

Bin ich IM Netzwerk (die DynDNS ist schon als DNS Rebind Ausnahme in der FritzBox), lande ich auf der Weboberfläche der FritzBox.
Port 443 wird also von der FritzBox abgefangen.

Warum? Keine Ahnung.... Passiert seit FritzOs 7.50, in 7.29 gab es das Problem nicht.

Wenn also jemand weiß, wie man in einem solchen Fall vorgeht, gerne Infos posten.
Ansonsten scheint das eher ein Sonderfall zu sein, über den hier ein paar Nerds stolpern.

 

[stoney]

Versuch mal die Paketbeschleunigung unter http://fritz.box zu deaktivieren bzw reichtbes ggf schon aus den Haken bei Hardwarebeschleunigung raus zu nehmen, sodass also die Beschleunigung aktiv ist, aber bei keiner Option ein Haken ist.

Evtl treten dann aber andere Nebeneffekte auf.

 

[Cyberrob90]

Auch ohne Paketbeschleunigung leider keine Besserung.

 

[frank_m24]

Bin ich IM Netzwerk (die DynDNS ist schon als DNS Rebind Ausnahme in der FritzBox), lande ich auf der Weboberfläche der FritzBox.

Das NAT-Loopback-Verhalten war immer schon unvorhersehbar. Grundsätzlich ist es keine gute Idee, Ports weiterzuleiten, die die Box selber für Server verwendet - sei es intern oder extern. Früher konnte man solche Portweiterleitungen gar nicht erst einrichten.

Die Kombination aus beiden Effekten ist alle Mal gut, das beobachtete Symptom zu erklären. Eine Lösung gibt es vermutlich nur durch Zufall und nicht dauerhaft stabil.

 

[Cyberrob90]

Hallo Frank,
die Lösung war 3 Jahre lang stabil, durch verschiedene FritzOs ab der 6er Reihe, sowie mit den Fritzboxen 7490, 7590 und eben CableVarianten.
Dass dies nur durch Zufall gehen soll, kann ich also nicht bestätigen, zumal versierte Programmierer in ihren Tutorials explizit zu dieser Art Portweiterleitung raten.
Wie sonst soll man auch sinnvoll einen Webserver hinter einer FritzBox betreiben?
Verwende ich einen anderen Port als 443, muss ich ihn ja explizit der URL anhängen.
Das wäre, meines Erachtens, die viel unsauberere Lösung. Schließlich will man ja einen möglichst einfachen Zugriff erreichen.

Oder gibt es da eine Alternative, wie ich ein redirect von beispiel.dyndns.de (gebunden an IPv4 und IPv6 der FritzBox) bei Aufruf direkt an den Port des im LAN laufenden Webservers übergebe?
Wobei ja der Aufruf von außerhalb ohnehin zuverlässig funktioniert. Es ist der interne Aufruf, der Sorge bereitet.
Ich kann nun natürlich stets die IP des Webservers eingeben.
Nervig ist dabei nur, dass dann das Zertifikat als nicht auf die IP ausgestellt gilt und somit Warnungen wirft.

 

[chrsto]

Je nach dem, wie viele Clients in dem internen Netz sind, könntest du entweder einen internen DNS Server aufsetzen, der die Zuordnung der Adresse auf die IP vornimmt, oder einfach die hosts Datei jedes Clients anpassen und so die Zuordnung vornehmen: a.myfritz.net -> 192.168.178.100 (als Beispiel)

 

[Cyberrob90]

Hallo chrsto,
der DNS Server wird hier die einzig gangbare Lösung sein, um das Problem nachhaltig in den Griff zu bekommen.
Wie schon weiter vorne im Thread erwähnt, kann ich die hosts Datei ja nur unter Windows Clients so modifizieren und nicht unter Android und iOs, weshalb dieser Weg für mich ausscheidet.
Zumal es bei portablen Geräten (Laptops) keine Trennung mehr gibt, zwischen LAN oder eben public Net.
Das würde dann NUR noch im richtigen Netz funktionieren, es sei denn, man tunnelt sich ohnehin immer per VPN. Das nur der Vollständigkeit halber, falls sonst jemand mal versucht wäre, die Lösung so umzusetzen und sich über die Seiteneffekte wundert

 

[frank_m24]

Dass dies nur durch Zufall gehen soll, kann ich also nicht bestätigen, zumal versierte Programmierer in ihren Tutorials explizit zu dieser Art Portweiterleitung raten.

Das gilt für Zugriffe von außen, aber nicht aus dem eigenen Netz. Da kommt dir NAT-Loopback dazwischen.

 

[sonyKatze]

wie man in einem solchen Fall vorgeht, gerne Infos posten

Der erste Schritt wäre zum Beispiel,
a) nachzubauen, was der Internet-Browser macht (DNS-A, TCP, TLS, HTTP) oder
b) mittels Wireshark auf dem Computer mitschneiden, was genau passiert.
Bei mir klappt das nämlich ohne Probleme, also Dienst unter 443 mit FRITZ!OS 7.50. Ich vermute, dass die DNS-Auflösung schon scheitert, vielleicht weil im Dynamic-DNS unter IPv6 die FRITZ!Box und nicht die NextCloud steht. Das müsste man sehen, indem Du

dig +short DeineDomain AAAA​

über eine Kommandozeile aufrufst. Die nächste Frage wäre, warum das vor FRITZ!OS 7.50 nicht auffiel.

Port 443 wird also von der FritzBox abgefangen

Der Thread handelt von zwei Dynamic-DNS. Hast Du das auch?

 

[Cyberrob90]

Hallo SonyKatze,

nachgebaut habe ich das mit DIG, soweit das unter Windows möglich war.
Ich erhalte als Antwort [A Record] die IP (v4) der FritzBox und auch die IPv6 bei [AAAA].
Bei der IPv4 ist das gewollt, weil die Weiterleitung per Port erfolgt, bei der IPv6 sollte also als Antwort schon die IPv6 der Cloud zurückgegeben werden?


Was bekomme ich im Browser zurück?
Fehlercode: SEC_ERROR_INADEQUATE_KEY_USAGE
wenn ich das Ganze im Browser versuche.
Analysiere ich das weiter, stellt man schnell fest, dass das Zertifikat der FritzBox übergeben wird, aber für diese Verbindung nicht akzeptiert wird. Warum? Gute Frage, denn die FritzBox trägt ja DynDNS Adressen mit ins Zertifikat ein. Aber ich will ohnehin nicht auf die Box und für die Cloud habe ich ein gültiges Let's Encrypt Zertifikat, weswegen ich da nicht weiter nachgeforscht habe.

In der FritzBox habe ich also ein DynDNS eingetragen, ja.
2 DNS?

Fehleranalyse:
Ich vermute, dass in älteren Versionen des FritzOS die IPv6 Unterstützung teilweise abgeschaltet war. Anwenderseitig, nicht von AVM.
Da Vodafone in den Mietboxen selbst einige EInstellungen vorgenommen hatte und ich erst vor wenigen Monaten die CableBox gekauft habe und dann eben auch gleich auf 7.5 gegangen bin, könnte man das nur nachstellen, indem man IPv6 von der Box wieder rausnimmt.
Aber das soll ja nicht die Lösung sein.
Zufällig eine Idee, wie ich die "richtige" IPv6 übergeben kann; also wie man die DNS Auflösung in den Griff bekommt?
Die DNS Server habe ich zwecks Geschwindigkeit auf die Google DNS Server gestellt, sowohl IPv4 als auch IPv6.

Viele Grüße
Robin

-- Zusammenführung Doppelpost gemäß Boardregeln https://www.ip-phone-forum.de/threads/ip-phone-forum-regeln.297224/ by stoney

@sonyKatze : Dein Beitrag lieferte den richtigen Denkanstoß.
Ich habe nun beim DynDNS-Anbieter einfach die IPv6 durch die Adresse der Cloud ersetzt; damit wird der Versuch eines IPv6 NAT, welches natürlich nicht funktionieren kann, nun verhindert und die Anfrage per IPv6 direkt an die Cloud geleitet. Anfragen per IPv4 landen bei der BOX und werden durch den Port weitergeleitet.
Klappt 1A.
Wenn ich jetzt noch den Parameter im DynDNS Befehl so einrichten kann, dass die IPv6 bei Aktualisierung nicht durch die der Box überschrieben wird, bin ich rundum glücklich. Aber das ist nur noch Feintuning.
Problem damit gelöst, vielen Dank!

 

[frank_m24]

Wenn ich jetzt noch den Parameter im DynDNS Befehl so einrichten kann, dass die IPv6 bei Aktualisierung nicht durch die der Box überschrieben wird, bin ich rundum glücklich.

Dafür muss entweder das NAS selber dyndns machen, oder du nutzt einen dyndns Anbieter, bei dem nur das Prefix aktualisiert wird, und trägst die Host-ID dort ein.

 

[sonyKatze]

Was frank_m24 als zweite Alternative beschreibt, findet sich im Forum auch unter dem Stichwort: ip6lanprefix. Aber dafür wirst Du vermutlich Deinen Dynamic-DNS-Anbieter tauschen müssen.