Ich habe ähnliche Problemberichte und Lösungsvorschläge gefunden, wobei die meisten davon blind geraten waren (Kernelmodul aktivieren) oder nicht beschrieben haben, warum was geändert wurde. Manche beschreiben ernsthaft aktives FTP, als ob heutzutage noch irgendein Client mit öffentlicher IP und ohne Firewall unterwegs wäre.
Was passiert: Ein externer FTP-Client verbindet sich mit dem FTP-Server hinter dem Lancom-Router, wobei nach dem Login die Verbindung abbricht, und zwar unmittelbar nach dem "PASV" vom Client (reset/abort, kein Timeout). Via IPv6 läuft es problemlos, nur IPv4 ist betroffen. Beim Kommandozeilenclient passiert es nach einem "ls" und lautet wie folgt:
Code: Alles auswählen
421 Service not available, remote server has closed connection
Passive mode refused.
Da nichts davon half, habe ich den Traffic mitgeschnitten und dabei festgestellt, dass der Server seine Antwort "227 Entering Passive Mode (1,2,3,4,192,91)." verschickt, diese aber nicht am Client ankommt. Der Lancom-Router verwirft diese Antwort offenbar und trennt die Verbindung. Warum?
An dieser Stelle wäre zu erwähnen, dass der Server zuvor bereits so eingestellt war, dass er seine öffentliche Adresse in die Antwort schreibt (im Beispiel durch 1.2.3.4 ersetzt). Ich verstehe zwar nicht, warum man dem Client die Serveradresse überhaupt in der Antwort mitteilen muss, wenn er sich zuvor selbst damit verbunden hat und sie also schon kennt, aber das ist halt FTP und wahrscheinlich hat sich jemand etwas dabei gedacht. (Wollte man damals etwa Load Balancing machen?)
Dass es mit IPv6 ging und daher nur Clients hinter reiner IPv4-Infrastruktur betroffen waren (ist ja nicht so, dass es IPv6 schon seit 20 Jahren gibt), sei nur am Rande erwähnt. Bei IPv6 läuft es ja auch anders, denn hier wird nicht "PASV" sondern "EPSV" verwendet, das Format in der Antwort unterscheidet sich und außerdem wird ohnehin direkt die IP vom Server angesprochen, ohne NAT.
Nachdem ich nicht weiterkam, hatte ich die Idee, den FTP-Server nicht mehr seine öffentliche IP verschicken zu lassen (MasqueradeAddress), wodurch FTP eigentlich nicht mehr funktionieren würde, da der entfernte Client die lokale IP des Servers bekommen würde, zum Beispiel 192.168.1.2, womit er sich natürlich nicht verbinden kann: 227 Entering Passive Mode (192,168,1,2,192,91).
Doch wider Erwarten hat diese Änderung den Fehler beseitigt, der Client konnte sich wieder verbinden. Dort kam die FTP-Antwort nun an, und zwar mit der öffentlichen IP des Servers, wie es sein sollte. Für einen Moment hatte ich befürchtet, dass der FTP-Server die IP fälschlicherweise noch für ein paar Stunden im Cache haben könnte, denn eigentlich hätte in der Antwort 192.168.1.2 stehen müssen und ich dachte schon, dass der Fehler bald wieder auftreten würde.
Dem war allerdings nicht so, wie ein erneuter Trafficmitschnitt zeigte. Der Server hat nach der Änderung seine interne IP 192.168.1.2 in die Antwort geschrieben, am Client kam die Antwort aber mit der öffentlichen IP an. Die Antwort wurde in dem Fall also nicht vom Router verworfen, sondern manipuliert. Offenbar handelt es sich um ein Feature, das den Anwendungstraffic manipuliert und in manchen Fällen ganz praktisch sein kann - wenn man denn darauf hingewiesen würde.
Es kam mir zuvor einfach überhaupt nicht in den Sinn, dass der Lancom-Router die FTP-Antwort auf "PASV" manipulieren könnte, indem er die Adresse darin ändert. Daher war mir auch zuvor nie die Einstellung "Check host IP address" aufgefallen, die in der Doku wie folgt beschrieben ist:
Nachdem dort "check" steht, hatte ich auch das erwartet und keine Adressmanipulation. Außerdem hatte ich bei den "unten konfigurierten Gegenmaßnahmen" ja bereits zuvor "ACCEPT" eingestellt.Wenn eine FTP-Session auf einem beliebigen Port erkannt wird, werden die konfigurierbaren Gegenmaßnahmen ergriffen. "Stations-IP-Adresse prüfen" gibt an, ob und auf welchen Routen die im FTP-Kommando-Kanal übermittelte Adresse gegen die Quelladresse des FTP-Clients geprüft werden soll. Stimmt sie nicht, werden die unten konfigurierten Gegenmaßnahmen ergriffen.
Warum verwirft der Lancom-Router denn aber die FTP-Antwort, wenn diese bereits die öffentliche IP enthält? Wo steht beschrieben, dass das passiert? Von der Existenz eines solchen Features müsste man doch auch ohne Trafficmitschnitt erfahren.