Lancom verwirft oder manipuliert FTP-Antwort "Entering Passive Mode"

Forum zum Thema Firewall

Moderator: Lancom-Systems Moderatoren

Antworten
problemkunde40
Beiträge: 25
Registriert: 20 Mär 2019, 12:49

Lancom verwirft oder manipuliert FTP-Antwort "Entering Passive Mode"

Beitrag von problemkunde40 »

Ich habe gerade relativ lange versucht herauszufinden, warum ein FTP-Server hinter einem neuen Lancom-Router (Firmware 10.32.0176RU9) nicht mehr funktioniert. Eigentlich sollte einen so etwas nicht besonders lange aufhalten, aber die FTP-Antwort wurde jedes Mal vom Lancom verworfen und ich konnte weder in der Konfiguration noch in der Dokumentation eine Erklärung finden, warum das passiert. Vor dem Netzwerkumzug lief noch alles, ohne dass sich die Serverkonfiguration geändert hätte. Mittlerweile habe ich eine Lösung, aber vielleicht hilft es jemandem oder vielleicht kann mir jemand die Stelle in der Doku zeigen.

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.
Zuerst habe ich natürlich an die Firewall gedacht, wo allerdings keine entsprechende Regel vorhanden ist. Die passiven Ports sind auch eingetragen, werden also an den FTP-Server weitergeleitet, wie in der Serverkonfiguration angegeben. In der Web-Konfiguration unter Configuration > Firewall/QoS > Applications, wo die Standardeinstellungen gesetzt waren, habe ich unter FTP den ersten Punkt "React on any FTP session" auf "No" gesetzt und sicherheitshalber bei "Application - Packet action" "ACCEPT" eingestellt, denn in der Dokumentation steht "Wenn eine FTP-Session auf einem beliebigen Port erkannt wird, werden die konfigurierbaren Gegenmaßnahmen ergriffen." Da auf der Seite nur diese eine Gegenmaßnahme konfiguriert werden kann, nahm ich an, dass die gemeint sein müsste.

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

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.
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: Lancom verwirft oder manipuliert FTP-Antwort "Entering Passive Mode"

Beitrag von backslash »

Hi problemkunde40
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).
und ganau das ist der Fehler. Die Firewall prüft, ob die Adresse in der PASV-Antwort mit der Adresse des Servers übereinstimmt (Einstellung "Stations-IP-Adresse prüfen"). Der Server muß einfach nur seine interne Adresse da eintragen - die wird vom NAT-Modul auf die öffentliche umgesetzt - aber das hast du ja alles selbst schon festgestellt
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?)
Das ist für den Site-2-Site-Transfer (FXP) gedacht, bei dem Dateien zwischen zwei Servern übertragen werden, die Contolle aber von einem anderen (= dritten) Client ausgeübt wird.
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.
EPSV funktioniert auch bei IPv4...
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.

Warum verwirft der Lancom-Router denn aber die FTP-Antwort, wenn diese bereits die öffentliche IP enthält?
Du hast es doch gerade selbst gesagt "check" prüft die Adresse... Das einzige, was mich wundert, ist daß die Session trotz "ACCEPT" getrennt werden soll.

Gruß
Backslash
problemkunde40
Beiträge: 25
Registriert: 20 Mär 2019, 12:49

Re: Lancom verwirft oder manipuliert FTP-Antwort "Entering Passive Mode"

Beitrag von problemkunde40 »

Danke, dass du dir die Zeit genommen hast, meine Geschichte zu lesen.
Die Firewall prüft, ob die Adresse in der PASV-Antwort mit der Adresse des Servers übereinstimmt (Einstellung "Stations-IP-Adresse prüfen"). Der Server muß einfach nur seine interne Adresse da eintragen - die wird vom NAT-Modul auf die öffentliche umgesetzt.
Mittlerweile habe ich ja herausgefunden, was die Firewall macht, aber als ich noch auf der Suche nach falschen Einstellungen in der Firewall war, habe ich solche Einstellungen wie "check xy" nicht weiter beachtet, da mir ein Check egal wäre, solange die Antwort des Servers durchgelassen wird. Wenn da "check" steht, erwarte ich, dass etwas geprüft wird und da ich sicherheitshalber zusätzlich "ACCEPT" ausgewählt hatte, bin ich auch davon ausgegangen, dass dieser Check, falls er theoretisch irgendwas verwerfen oder ablehnen könnte (wenn die geprüfte Bedingung nicht zutrifft), die Daten nach der Prüfung dennoch akzeptieren und durchlassen sollte. Da die FTP-Antwort weiterhin verschwand, sah ich diese Einstellung nicht mehr als relevant an, konnte aber eben auch sonst keine Einstellung finden, welche dafür verantwortlich sein könnte, dass die FTP-Verbindung abgebrochen wird.

Und dass die Antwort des Servers, falls sie nicht die öffentliche, sondern die interne IP enthält, zusätzlich umgeschrieben wird, wäre mir niemals in den Sinn gekommen, wenn ich eine Einstellung sehe, die etwas "prüft". Bitte nicht falsch verstehen, im Nachhinein kann ich erkennen, dass sich jemand bei diesem Feature viel Mühe gegeben hat und es kann ja auch in gewissen Setups durchaus praktisch sein. Aber wenn man davon nichts weiß, nirgendwo steht, dass eine bestimmte Einstellung FTP-Verbindungen abbrechen wird (oder wo ist das Feature beschrieben?), dann kommt einem so etwas wie eine unerwartete Fehlfunktion vor, bis man dann durch eine Trafficanalyse Rückschlüsse auf die gewünschte Funktionsweise getroffen hat.

Ach ja, ich habe diese Einstellung gerade testweise auf "No" geändert und es hat sich nichts geändert.
Das ist für den Site-2-Site-Transfer (FXP) gedacht, bei dem Dateien zwischen zwei Servern übertragen werden, die Contolle aber von einem anderen (= dritten) Client ausgeübt wird.
Interessant. Nur schade, dass jeder, der FTP machen will, deshalb darunter leiden muss, weil die Serveradresse vom Server an den Client geschickt werden muss.
EPSV funktioniert auch bei IPv4...
Mag sein, aber wie würde mir das in einer solchen Situation helfen?
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: Lancom verwirft oder manipuliert FTP-Antwort "Entering Passive Mode"

Beitrag von backslash »

Hi problemkunde40
Und dass die Antwort des Servers, falls sie nicht die öffentliche, sondern die interne IP enthält, zusätzlich umgeschrieben wird, wäre mir niemals in den Sinn gekommen,
wieso nicht? Das LANCOM untesrtützt FTP im NAT - und zwar vollstzändig. Das ist seit über 30 Jahren State-Of-The-Art - auch wenn es die gaazen Home-Router bis heute nicht können.
es kann ja auch in gewissen Setups durchaus praktisch sein.

was heißt "in gewissen Setups". Das ist eigentlich das Standard-Szenario, wenn man einen FTP-Server hinter einer dynamischen Adfresse betreibt. Ohne die NAT-Unterstützung im Router muß man da alle möglichen und unmöglichen Klimmzüge machen (Stichwort: NAT-Helper), damit das auch nur halbwegs funktioniert.
Aber wenn man davon nichts weiß, nirgendwo steht, dass eine bestimmte Einstellung FTP-Verbindungen abbrechen wird (oder wo ist das Feature beschrieben?), dann kommt einem so etwas wie eine unerwartete Fehlfunktion vor, bis man dann durch eine Trafficanalyse Rückschlüsse auf die gewünschte Funktionsweise getroffen hat.
Zum einen wirfst du hier zwei Dinghe durcheinander (NAT-Support und Adreßprüfung) und zum manderen hat man das Problem nur, wenn man vorher nur mit Home-Routern und den dafür nötigen kruden NAT-Helpern gearbeitet hgat und sich deshalb gar nicht vorstellen kann, daß es auch besser geht - und wie gesagt: Für FTP das ist seit Jahrzehnten State-Of-The-Art...

Interessant. Nur schade, dass jeder, der FTP machen will, deshalb darunter leiden muss, weil die Serveradresse vom Server an den Client geschickt werden muss.
das steht nunmal so im RFC und ist somit eh nicht änderbar

Mag sein, aber wie würde mir das in einer solchen Situation helfen?
bei EPSV schreibt der Router die Adresse nicht um, sondern öfnnet einfach nur die Session, d.h. du brauchst selbst bei Home-Routern keinen NAT-Helper für den FTP-Server - dafür aber Clients die EPSV machen... Oder noch besser: du verbietest PASV einfach - dann muß gar nichts umgeschreiben werden (zumindest wenn du dann auch noch ein Portforwarding für den Datankanal einrichtest)

Gruß
Backslash
problemkunde40
Beiträge: 25
Registriert: 20 Mär 2019, 12:49

Re: Lancom verwirft oder manipuliert FTP-Antwort "Entering Passive Mode"

Beitrag von problemkunde40 »

Und dass die Antwort des Servers, falls sie nicht die öffentliche, sondern die interne IP enthält, zusätzlich umgeschrieben wird, wäre mir niemals in den Sinn gekommen
wieso nicht?
Wie schon gesagt - weil das nicht dort stand.
Ohne die NAT-Unterstützung im Router muß man da alle möglichen und unmöglichen Klimmzüge machen (Stichwort: NAT-Helper), damit das auch nur halbwegs funktioniert.
Wenn die FTP-Antwort nicht geblockt worden wäre, hätte es von Anfang an funktioniert, ohne Helper und dergleichen. Aber wenn man schon eine FTP-Unterstützung im Router hat, ist es natürlich sinnvoller, diese auch zu nutzen. Bitte nicht falsch verstehen. Ich nutze sie ja auch gerne, seitdem ich durch meine Trafficanalyse herausgefunden habe, dass sie funktioniert, sobald der FTP-Server seine interne Adresse in die Antwort schreibt.
Aber wenn man davon nichts weiß, nirgendwo steht, dass eine bestimmte Einstellung FTP-Verbindungen abbrechen wird (oder wo ist das Feature beschrieben?), dann kommt einem so etwas wie eine unerwartete Fehlfunktion vor, bis man dann durch eine Trafficanalyse Rückschlüsse auf die gewünschte Funktionsweise getroffen hat.
Zum einen wirfst du hier zwei Dinghe durcheinander (NAT-Support und Adreßprüfung)
Inwiefern habe ich NAT-Support hineingemischt? Die FTP-Antwort wird doch durch die Adressprüfung verworfen (obwohl die "Gegenmaßnahme" "ACCEPT" sein sollte).
dafür aber Clients die EPSV machen... Oder noch besser: du verbietest PASV einfach
Wenn ich PASV verbiete, wird es ja wieder nicht funktionieren. Dann würde der Server das PASV ablehnen und der Client würde aufgeben. Wenn sich jemand mit einem FTP-Server verbinden will und dieser dann mit 501 "not permitted" oder "refused" antwortet, wäre das aus Client-Sicht kein funktionierender FTP-Server.
wenn du dann auch noch ein Portforwarding für den Datankanal einrichtest
Das war von Anfang an eingestellt.
Antworten