Der Labor-"ftpd" hat doch offensichtlich das Problem, daß er mit der internen Adresse auf den PASV-Befehl reagiert, auch wenn die Verbindung von extern erfolgte. Diese Antwort enthält ja eine Ansage des Servers, auf welcher Adresse und auf welchem Port der Client seine Datenverbindung aufbauen soll und da steht ja ganz offensichtlich auch bei externem Zugriff die lokale IPv4-Adresse drin, womit der externe Client schlicht nichts anfangen kann.
Da dann auch das ALG für FTP nicht erkennen kann, daß dort eine zusätzliche temporäre Portfreigabe notwendig ist (die vom Client eingehende Datenverbindung muß ja aus dem WAN auch an den ftpd weitergeleitet werden), kann das auch mit einem FTP-Client, der anstelle der IP-Adresse in der PASV-Response einfach die Server-Adresse verwendet (wie es FileZilla ja versucht zu lösen), nur dann funktionieren, wenn irgendjemand (entweder das ALG oder der ftpd selbst) diese zusätzliche eingehende Verbindung ermöglicht. Solange das nicht erfolgt - was offenbar ein neues Problem in der Labor-Version ist - wird jeder Versuch des Clients scheitern, eine Datenverbindung aufzubauen.
Es gab bisher eine etwas eigentümliche Konstruktion im Code des ftpd, um das "Quell-Interface" einer FTP-Verbindung zu ermitteln. Offenbar versucht AVM nun, diesen Code-Teil sinnvollerweise zu ändern (er könnte für Angriffe auf den FTP-Server mißbraucht werden, wenn es gelingt, externe Verbindungen als intern auszugeben und von innen per Einstellung keine Authentifizierung notwendig ist bzw. dann ein Konto ohne externe Berechtigungen verwendet werden kann) und dabei klappt dann die korrekte Einordnung der Verbindung nicht.
Oder das ALG in der FRITZ!Box (keine Ahnung, wo das stecken könnte bzw. ob es überhaupt dort eingreifen würde) vergißt es einfach, die PASV-Response zu untersuchen und daraus die richtigen Schlüsse zu ziehen. Wenn das ALG die Antwort so ändern würde, daß da wieder die externe IP-Adresse steht und dann auch noch eine passende temporäre Portfreigabe eingerichtet wird, dann klappte das sogar für FTP-Server im LAN hinter der FRITZ!Box ... solange da nicht die Control-Verbindung schon verschlüsselt wird. Auch das könnte eine "Falle" in diesem Konstrukt werden ... denn wenn der FTP-Server der FRITZ!Box die Control-Verbindung verschlüsselt, dann "sieht" der restliche Code die PASV-Response ja nicht mehr im Klartext und kann sie weder richtig behandeln noch irgendwie ändern. Mir ist im Moment gerade auch absolut nicht klar, wie AVM diese Klippe umschifft ... das interessiert mich jetzt doch.
Die internen Ursachen können also vielfältig sein, über die tatsächlichen Abläufe und Zusammenhänge zwischen ftpd und Firewall/ALG ist meines Wissens zu wenig bekannt (man kann nur in den bisherigen OSS-Quellen sehen, daß da keine "Steuerung" von Portfreigaben durch den ftpd erfolgte, also müßte das eigentlich alles per ALG gelaufen sein). Man könnte das zwar durch einige Tests versuchen zu ermitteln ... but who cares?
Es ist einfach falsch, wenn in der PASV-Response (die beim Client ankommt) die interne Adresse steht und schon der Versuch einiger FTP-Clients, in so einem Fall die Adresse zu ignorieren und stattdessen die Server-Adresse zu verwenden, ist eigentlich ein Protokoll-Verstoß und nur ein schlechter Workaround.
AVM wird sich kaum auf solche Spezialitäten eines FTP-Clients verlassen wollen ... sie werden es sicherlich noch gebacken kriegen. Vielleicht liegt es auch an einer spezielleren Kombination aus "Router-Mode" und "Verbindung über LAN1"? Ich kann mir eigentlich nicht vorstellen, daß es tatsächlich immer auftritt und damit praktisch ungetestet wäre - schon gar nicht über mehrere Labor-Versionen.
Mit DNS-Rebind hat das aber alles nichts zu tun ... innerhalb des FTP-Protokolls werden keine DNS-Namen mehr verwendet, da geht es nur noch um IP-Adressen. Der Rebind-Schutz soll ja nur verhindern, daß externe DNS-Antworten auf interne IP-Adressen verweisen, was für Angriffe genutzt werden kann und bei bestimmten Konstellationen (eigene DNS-Server, VPN, usw.) trotzdem notwendig sein kann.
