Ich versuche verzweifelt eine PASV Verbindung mit dem internen FTP Server von außen aufzubauen... irgendwas zickt da...
FTP Server: proFTPd (Linux), IP 192.168.1.1
LANCOM 1724: 192.168.1.254
keine Firewall Regeln definiert.
Von einem externen PC mache ich eine Verbindung zu meinem Lancom über Port 21, die Verbindung wird aufgebaut, user und pw eingabe erfolgreich.
sobald ich ein "dir" oder "ls" mache, will der Client eine Passive Verbindung zum FTP Server aufbauen und genau dort bleibt er hängen.
LANCOM Config:
IP Router > Maskierung > Service-Tabelle
1) 21-21 > 192.168.1.1:21 Aktiv:Ja
2) 60.000-62.000 > 192.168.1.1:60.000 Aktiv:Ja
im proFTPd Server habe ich eingestellt das er den PASV Port Bereich auf 60.000 bis 62.000 einschränken soll (so das ich kein Forward von 1024 bis 65535 brauche)
Ich habe das per netstat -lnp schon überprüft, bei aktiver Verbindung, wählt der Server einen Port aus diesem Bereich aus, z.b. 61356
Hab mal ne Log Firewall Regel angelegt mit SNMP Trap, es wird auch geloggt das über genau diese Ports eine Verbindung reinkam, wurde mit nem Grünen Harken im Montior bestätigt.
ein
tcpdump -vv -i eth0 src portrange 60000-62000, spuckt folgende Pakete aus, direkt nach dem cmd "dir":
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 68 bytes
00:38:48.432919 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 60) server1.61112 > client-pc.48770: S 3792476673:3792476673(0) ack 1746793127 win 5792 <mss 1460,sackOK,timestamp 21766799[|tcp]>
00:38:51.423700 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 60) server1.lange.local.61112 > axw1.artada.de.48770: S 3795467473:3795467473(0) ack 1746793127 win 5792 <mss 1460,sackOK,timestamp 21767547[|tcp]>
das sieht so aus, als will die TCP Sitzung eine ACK Paket zurück an den FTP-Client senden, und versucht das immer und immer wieder
(bis zu 7 mal)
Danach meldet der FTP Client n time-out.
Kann mir nich helfen... eine interne PASV Verbindung zum FTP Server läuft einwandfrei, die Logs sind sauber, Port passt auch..
hab das Gefühl der LANCOM blockt irgendwas.
Grüße
Jan
FTP Server im internen Netz freigeben (Passive Ports)
Moderator: Lancom-Systems Moderatoren
FTP Server im internen Netz freigeben (Passive Ports)
LANCOM 1724 | Auerswald Commander Basic
Hi,
ich nochmal... hab nun auf einer Windows Kiste Serv-U installiert als FTP Server.
Habe hier genau das gleiche phänomen. Die Verbindung über diese Ports geht nicht durch!!
Hab den LANCOM gegen eine Fritz.box getauscht... schwups... es ging sofort ohne probleme.
wo dran liegt das?
Gruß Jan
ich nochmal... hab nun auf einer Windows Kiste Serv-U installiert als FTP Server.
Habe hier genau das gleiche phänomen. Die Verbindung über diese Ports geht nicht durch!!
Hab den LANCOM gegen eine Fritz.box getauscht... schwups... es ging sofort ohne probleme.
wo dran liegt das?
Gruß Jan
LANCOM 1724 | Auerswald Commander Basic
Re: FTP Server im internen Netz freigeben (Passive Ports)
Hi,
Probier das mal mit Map-Port: 0 bei beiden.
Du willst doch den Port weiterleiten und nicht mappen?!LANCOM Config:
IP Router > Maskierung > Service-Tabelle
1) 21-21 > 192.168.1.1:21 Aktiv:Ja
2) 60.000-62.000 > 192.168.1.1:60.000 Aktiv:Ja
Probier das mal mit Map-Port: 0 bei beiden.
Gruß
Jens
...online mit 1784VA (VDSL 100) + WLC-Option
WLAN mit L-1302 / L-1310 / OAP-830
LAN über GS-1224
Jens
...online mit 1784VA (VDSL 100) + WLC-Option
WLAN mit L-1302 / L-1310 / OAP-830
LAN über GS-1224
Ja hab ich auch schon gesehen im Handbuch und in der KB von Lancom.... hab ich geändert auf "leer" bzw 0
hat aber nichts gebracht
gleicher effekt...
Allerdings hab ich bei ICQ ne Portrange von 5001 bis 5050 angegeben und dort auch map port 5001 eingetragen, was bisshe rimmer funktioniert hat beim file-transfer.
hat aber nichts gebracht
gleicher effekt...
Allerdings hab ich bei ICQ ne Portrange von 5001 bis 5050 angegeben und dort auch map port 5001 eingetragen, was bisshe rimmer funktioniert hat beim file-transfer.
LANCOM 1724 | Auerswald Commander Basic
Hi janlange
Das Problem ist hier, daß durch deinen Eintrag in der Service-Tabelle, die Antworten des FTP-Servers nicht mehr beim Client ankommen - genaugenommen kommen sie vom dem falschen Quellport (nämlich 6xxxx, statt dem, den das LANCOM zugewiesen hat) weshalb sie ins leere laufen.
Gruß
Backslash
nimm den zweiten Eintrag (60000-62000) weg und es wird gehen - ebenso kannst du die Portbeschränkung auf deinem FTP-Serves entfernen. Das LANCOM erkennt nämlich - anders als die "hochgelobte" Fritzbox - passive FTP-Verbindung von ganz alleine. Nur wenn der Anwender "schlauer" sein will gibt's Probleme.1) 21-21 > 192.168.1.1:21 Aktiv:Ja
2) 60.000-62.000 > 192.168.1.1:60.000 Aktiv:Ja
Das Problem ist hier, daß durch deinen Eintrag in der Service-Tabelle, die Antworten des FTP-Servers nicht mehr beim Client ankommen - genaugenommen kommen sie vom dem falschen Quellport (nämlich 6xxxx, statt dem, den das LANCOM zugewiesen hat) weshalb sie ins leere laufen.
Gruß
Backslash
Hi Backslash,
danke für die Info.. da das Forum hier seit 1 Woche defekt war, hab ich in dieser Woche schon Kontakt mit dem LANCOM Support aufgenommen.
Die haben mir genau das gleiche erzählt, und es funktioniert auch. Schade find ich das es nich im Handbuch steht das LANCOM NAT-Helper in dem dingen benutzt.
Desweiteren hab ich zu Testzwecken eine 6.16 Beta Firmware bekommen, dort wurde ne Verbesserung eingebaut, so dass wenn statische PASV Portmappings in der Forward Tabelle drin sind, sich der NAT-Helper ausschaltet.
Ich hab aber immernoch ein Problem (mit beiden Firmwares), wo sich der LANCOM Support zur Zeit auch noch drüber den Kopf zerbricht.
FTP (explicit) SSL/TLS Verbindungen funktionieren nicht mit Passive Ports, wird eine Passive Datenverbindung aufgebaut bleibt die Verbindung wieder am Router "hängen" egal ob mit oder ohne Service-NAT Eintrag.
Vermutlich sieht der LANCOM die Verbindung auf Port 21, kann die Befehle aber nich mitlesen wegen der Verschlüsselung und öffnet somit nich dynamisch die Passiven Ports.
Gleichzeitig wird aber auch irgendwie in der 6.16er Firmware der NAT-Helper nicht deaktiviert, weil er wohl auch hier vermutlich nich erkennt, das es sich um FTP Daten handelt.
Najo... abwarten was kommt.. kann ja hier berichten.
Wundert mich nur das hier noch nie jemand ein internen verschlüsselten FTP Server genutzt hat mit nem LANCOM Router ^_^
Grüße Jan
danke für die Info.. da das Forum hier seit 1 Woche defekt war, hab ich in dieser Woche schon Kontakt mit dem LANCOM Support aufgenommen.
Die haben mir genau das gleiche erzählt, und es funktioniert auch. Schade find ich das es nich im Handbuch steht das LANCOM NAT-Helper in dem dingen benutzt.
Desweiteren hab ich zu Testzwecken eine 6.16 Beta Firmware bekommen, dort wurde ne Verbesserung eingebaut, so dass wenn statische PASV Portmappings in der Forward Tabelle drin sind, sich der NAT-Helper ausschaltet.
Ich hab aber immernoch ein Problem (mit beiden Firmwares), wo sich der LANCOM Support zur Zeit auch noch drüber den Kopf zerbricht.
FTP (explicit) SSL/TLS Verbindungen funktionieren nicht mit Passive Ports, wird eine Passive Datenverbindung aufgebaut bleibt die Verbindung wieder am Router "hängen" egal ob mit oder ohne Service-NAT Eintrag.
Vermutlich sieht der LANCOM die Verbindung auf Port 21, kann die Befehle aber nich mitlesen wegen der Verschlüsselung und öffnet somit nich dynamisch die Passiven Ports.
Gleichzeitig wird aber auch irgendwie in der 6.16er Firmware der NAT-Helper nicht deaktiviert, weil er wohl auch hier vermutlich nich erkennt, das es sich um FTP Daten handelt.
Najo... abwarten was kommt.. kann ja hier berichten.
Wundert mich nur das hier noch nie jemand ein internen verschlüsselten FTP Server genutzt hat mit nem LANCOM Router ^_^
Grüße Jan
LANCOM 1724 | Auerswald Commander Basic
Hallo Jan,
welchen FTP Client benutzt du?
FlashFXP ist hier insb. bei SSL/TLS verbindungen erste Wahl.
Dort kannst du implizites/explizites FTPs einsetzen.
Und genau selektieren, ob nur der AUTH oder auch die DATA connection verschlüsselt sein soll. Weiterhin kann er SSCN commandos deuten.
Also hast du genau eingige Möglichkeiten den Übeltäter des Problem zu lokalisieren, wenn du die Verschiedenen Parameter ausprobierst
Falls das Problem nur mit dem NAT-Helper nur bei DATA connections auftriff, die verschlüsselt sind, dann hat der LANCOM keinen Einblick in die Daten und kann somit nicht per SPI Firewall die erforderlichen Ports öffnen.
Per statischen Passive Port Range im FTP und FTP Server sollte es aber in jedem Fall funktionieren.
Halte uns mal auf den Laufenden. Welche sonstigen Neuerungen hat die 6.16 Beta denn?
welchen FTP Client benutzt du?
FlashFXP ist hier insb. bei SSL/TLS verbindungen erste Wahl.
Dort kannst du implizites/explizites FTPs einsetzen.
Und genau selektieren, ob nur der AUTH oder auch die DATA connection verschlüsselt sein soll. Weiterhin kann er SSCN commandos deuten.
Also hast du genau eingige Möglichkeiten den Übeltäter des Problem zu lokalisieren, wenn du die Verschiedenen Parameter ausprobierst
Falls das Problem nur mit dem NAT-Helper nur bei DATA connections auftriff, die verschlüsselt sind, dann hat der LANCOM keinen Einblick in die Daten und kann somit nicht per SPI Firewall die erforderlichen Ports öffnen.
Per statischen Passive Port Range im FTP und FTP Server sollte es aber in jedem Fall funktionieren.
Halte uns mal auf den Laufenden. Welche sonstigen Neuerungen hat die 6.16 Beta denn?
Hi,
ich nutze FlashFXP und FTP Voyager
egal ob explict TLS oder SSL, und auch egal ob mit oder ohne Verschlüsselung nach der Authentifizierung (Clear)...
es funzt nicht.
Ich vermute der NAT-Helper erkennt am Anfang zwar eine FTP verbindung, kann damit aber nix anfangen... Somit funktioniert das dynamische Portforwarding nicht, und das Statische scheinbar auch nicht (mit der 6.16) da (ich vermute es mal auf Basis meines zusammengereimten Wissens) er wohl erkennt das es sich um FTP handelt, aber irgendwie auch doch nicht.
Daraus folgt das dynamisch nicht ghet, weil er erkennt die PASV befehle nicht, und statisch auch nicht, weil der NAT-Helper sich nicht deaktiviert, da er anscheinend zwar erkennt das es wohl was mit FTP zu tun hat, und sich somit nich abschaltet.
Fänds besser wenn LANCOM da einfach eine Option reinmacht "NAT-Helper aus". Ein dummer Router (like fritzbox) mit Portforwarding kriegt es ja auch hin. Und schließlich wurde ja wegen dem NAT Problems in den FTP Servern Optionen zur Beschränkung der Portrange eingebaut, um dieses Problem zu umgehen.
proFTPd Server kann nämlich auch die IP Adresse Maskieren, und bei Verbindungen die öffentliche benutzen. Das funktioniert der NAT-Helper von LANCOM nämlich auhc nicht mehr mit dynamischen Forwarding *ups*
Aber so ist es eigentlich "besser" weil externe FTP Clients/Server denken, der Server ist öffentlich erreichbar ohne NAT. So das es keine PRobleme mit der Privaten IP gibt.
Grad beim FXP'en kommts schonmal vor das die Private IP beim PASV kommando genutzt wird, und somit die Verbindung ins leere führt.
Bisjetzt kam noch keine Antwort von LANCOM, der Supporter will mein Problem in einer Testumgebung nachstellen. Mal abwarten.
Gruß Jan
ich nutze FlashFXP und FTP Voyager
egal ob explict TLS oder SSL, und auch egal ob mit oder ohne Verschlüsselung nach der Authentifizierung (Clear)...
es funzt nicht.
Ich vermute der NAT-Helper erkennt am Anfang zwar eine FTP verbindung, kann damit aber nix anfangen... Somit funktioniert das dynamische Portforwarding nicht, und das Statische scheinbar auch nicht (mit der 6.16) da (ich vermute es mal auf Basis meines zusammengereimten Wissens) er wohl erkennt das es sich um FTP handelt, aber irgendwie auch doch nicht.
Daraus folgt das dynamisch nicht ghet, weil er erkennt die PASV befehle nicht, und statisch auch nicht, weil der NAT-Helper sich nicht deaktiviert, da er anscheinend zwar erkennt das es wohl was mit FTP zu tun hat, und sich somit nich abschaltet.
Fänds besser wenn LANCOM da einfach eine Option reinmacht "NAT-Helper aus". Ein dummer Router (like fritzbox) mit Portforwarding kriegt es ja auch hin. Und schließlich wurde ja wegen dem NAT Problems in den FTP Servern Optionen zur Beschränkung der Portrange eingebaut, um dieses Problem zu umgehen.
proFTPd Server kann nämlich auch die IP Adresse Maskieren, und bei Verbindungen die öffentliche benutzen. Das funktioniert der NAT-Helper von LANCOM nämlich auhc nicht mehr mit dynamischen Forwarding *ups*
Aber so ist es eigentlich "besser" weil externe FTP Clients/Server denken, der Server ist öffentlich erreichbar ohne NAT. So das es keine PRobleme mit der Privaten IP gibt.
Grad beim FXP'en kommts schonmal vor das die Private IP beim PASV kommando genutzt wird, und somit die Verbindung ins leere führt.
Bisjetzt kam noch keine Antwort von LANCOM, der Supporter will mein Problem in einer Testumgebung nachstellen. Mal abwarten.
Gruß Jan
LANCOM 1724 | Auerswald Commander Basic
Wie haste das denn gemacht?!?
Aktiv oder Passive??
Aktiv geht ja.. nur passiv nicht.
und bei FXP musse aufpassen, wer die verbindung aufbaut
FXP von wem anders auf meinem geht nämlich. Weil dadurch mein FTP server ne verbindung zu dem anderen macht. So kommt SNAT bei mir gar nich erst zum einsatz.
Aktiv oder Passive??
Aktiv geht ja.. nur passiv nicht.
und bei FXP musse aufpassen, wer die verbindung aufbaut
FXP von wem anders auf meinem geht nämlich. Weil dadurch mein FTP server ne verbindung zu dem anderen macht. So kommt SNAT bei mir gar nich erst zum einsatz.
LANCOM 1724 | Auerswald Commander Basic
Hi janlange,
hast du eigentlich nach erhalt der 6.18 auch den Portrange für die passiven verbindungen in deinem Server wieder eingeschaltet?
bei SFTP kann das LANCOM gar nicht wissen, welche Ports da ausgehandelt werden (ist ja verschlüsselt), deshalb behandelt es die weitergeleiteten Ports genau so als würdest du z.B. den Port 80 weiterleiten.
Wenn du aber wie in meinem ersten Posting geraten, den Port-Bereich gelöscht hast, dann handelt der Server nun ja irgendwelche Ports aus, in aber nicht weitergeleitet wurden
Gruß
Backslash
hast du eigentlich nach erhalt der 6.18 auch den Portrange für die passiven verbindungen in deinem Server wieder eingeschaltet?
bei SFTP kann das LANCOM gar nicht wissen, welche Ports da ausgehandelt werden (ist ja verschlüsselt), deshalb behandelt es die weitergeleiteten Ports genau so als würdest du z.B. den Port 80 weiterleiten.
Wenn du aber wie in meinem ersten Posting geraten, den Port-Bereich gelöscht hast, dann handelt der Server nun ja irgendwelche Ports aus, in aber nicht weitergeleitet wurden
Gruß
Backslash
Hi Backslash,
hab grad Antwort vom Support bekommen.... Toll die schieben das auf meinen FTP Server..
kann ich mir aber nicht im geringsten vorstellen.
Um deine Aussage oben zu beantworten: Ich hab alles überprüft. Portforwarding von 60.000 bis 60.049 hab ich eingetragen, desweiteren hab ich im proftpd Server diese Portrange auch eingetragen.
FTP Logins ohne SSL gehen, mit SSL bleibts wie immer bei der Passiven Verbindung hängen.
laut netstat öffent der FTP Server korrekt einen Port zwischen dieser Range, und wartet auf Verbindung.
Mach ich intern einen Test mit SSL und Passiv Mode funktioniert es wunderbar.
Ich verstehs nich..
hab grad Antwort vom Support bekommen.... Toll die schieben das auf meinen FTP Server..
kann ich mir aber nicht im geringsten vorstellen.
Um deine Aussage oben zu beantworten: Ich hab alles überprüft. Portforwarding von 60.000 bis 60.049 hab ich eingetragen, desweiteren hab ich im proftpd Server diese Portrange auch eingetragen.
FTP Logins ohne SSL gehen, mit SSL bleibts wie immer bei der Passiven Verbindung hängen.
laut netstat öffent der FTP Server korrekt einen Port zwischen dieser Range, und wartet auf Verbindung.
Mach ich intern einen Test mit SSL und Passiv Mode funktioniert es wunderbar.
Ich verstehs nich..
LANCOM 1724 | Auerswald Commander Basic