eher ein nachträglich schöngeredeter Praktikantenfehler.
Ganz so kritisch würde ich das dann doch wieder nicht sehen ... im Gegensatz zu den Verbindungen, welche die FRITZ!Box von der WAN-Seite erreichen und über entsprechende Einträge in den Tabellen des PA realisiert werden (da werden die Daten ja direkt zum internen Gerät weitergereicht, nachdem die Pakete harewareseitig entsprechend geändert wurden), nehmen die Pakete von innen eben doch einen komplett anderen Weg in ihrer Verarbeitung.
Und der DNS-Name wird nun mal (für mich nachvollziehbar) in die (externe) Adresse der FRITZ!Box aufgelöst - anschließend muß dann der Router wieder über "NAT hairpinning" (anhand der Tatsache, daß da seine eigene Adresse als Ziel enthalten ist) dafür sorgen, daß die Pakete ins LAN entsprechend "umgeschrieben" werden (das geht ja nicht über die Hardware ins WAN) und dabei noch aufpassen, daß er die Adresse des echten Absenders durch seine eigene ersetzt, da ansonsten die Antwort des Servers direkt an den Client gehen würde und von diesem (mit hoher Wahrscheinlichkeit) verworfen würde (sofern der seine eigene Firewall betreibt), weil die Pakete aus seiner Sicht von der falschen Adresse kommen (anstatt von der öffentlichen IP der FRITZ!Box).
Dieser Mechanismus des "NAT-Loopback" bzw. "NAT-Hairpinning" ist also - hinsichtlich des Handlings der Pakete - nicht so ganz einfach ... gerade dann, wenn der Rest ansonsten zum größten Teil am Router-OS "vorbeigehen" würde und keiner gesonderten Behandlung bedarf ... und auf diesem Weg funktionieren die Zugriffe (den Berichten nach) ja offenbar auch.
Das würde ich also nicht als "Praktikantenfehler" einstufen ... auch wenn es ein - neu eingeschleppter - Fehler sein mag, der dann eben in der nächsten Version behoben werden sollte.
Was ich mich hingegen in solchen Fällen immer wieder mal frage ... warum läßt man es eigentlich den Herstellern der betroffenen Client-Apps immer "durchgehen", wenn diese keine Einstellung des zu verwendenden Ports gestatten? Was macht man denn, wenn man auf einmal zwei Services auf zwei getrennten Geräten im LAN nutzen will und die Client-Apps dieser beiden Dienste bestehen unbedingt darauf, nun jeder für sich den Port 443 beanspruchen zu wollen? Ich würde als Erstes mal hier ansetzen ... auch wenn das derzeitige Verhalten durchaus als Fehler in der AVM-Firmware zu werten ist.
Aber schließlich betrifft das auch nur die Szenarien, wo es unbedingt (von innen und von außen) der Port 443 sein MUSS, den die Client-Software da verwenden will - warum denkt eigentlich niemand (zumindest nicht laut) darüber nach, warum wohl die Anbieter irgendwelcher Server-Software und/oder Client-Apps hier ihre Hausaufgaben nicht machen und den Benutzer dazu zwingen, unbedingt solche "well-known ports" zu verwenden, wenn doch bekannt ist, daß man darüber/darauf auch ganz wunderbar DDoS-Attacken fahren kann? Hier muß letztlich der Router das "ausbessern", was die Server- und/oder die Client-Software versäumt ... in diesem Falle geht das nun eben mal schief. Na und?
Ich persönlich finde es jedenfalls allemal besser (und wichtiger), daß man das GUI der Box jetzt auch von innen mit einem normalen Browser durch Angabe von HTTPS-URLs (ohne explizite Angabe einer Port-Nummer, denn das macht dann im Browser wirklich nur noch der ganz, ganz Hartgesottene) benutzen kann ... wenn irgendwelche anderen Apps mit fest eingestellten URLs und/oder Zugangsdaten dann jetzt auf einen anderen Port ausweichen müssen (im Moment ist es ja nur ein Workaround und noch nicht "geplante Funktionsweise"), dann ist das eben so.
Wenn diese Apps keine flexibleren "Vorgaben" für ihre URLs beherrschen (so in der Art: "Im Netzwerk ABC verwendet IP-Adresse 1.2.3.4, ansonsten 5.6.7.8.") oder gar mehrere Profile für unterschiedliche Zugangswege, dann sollte man auch nicht unbedingt die FRITZ!Box dafür verantwortlich machen ... die mangelnde Flexibilität kommt da von ganz anderer Seite und ohne diese, entstünde das Problem ebenfalls nicht.
