Langsamer FTP Verbindungsaufbau
-
Hallo gemeinde,
ich habe ein Problem mit der Verbindung zu FTP Servern, unzwar dauert der connect bis auf den FTP verbunden wird sehr lange zwischen 5-10 Sekunden. Da ich per scripte sehr häufig auf Ftp server connecte ist das ärgerlich. Ich betreibe Selber einen FTP server er untersützt sowohl Passive als auch Aktive Verbindungen. Die Verbindungen selbst sind aber kein Problem der Down/Upload funktioniert einwandfrei, ledeglich das Connecten auf die Server dauert durch pfsense sehr lange.
Hat jemand evtl einen Tip mit welchen setting ich es in pfsense etwas beschleunigen kann ?MFG
-
Dein Problem ist konkret: Du hast Clients hinter einer pfSense die sich auf FTP Server verbinden und der Verbindungsaufbau ist langsam?
Hast du auf den Clients schon Mal von passiv/aktiv auf die jeweils andere Methode umgeschaltet?Gruß
-
Hi JeGr,
Dein Problem ist konkret: Du hast Clients hinter einer pfSense die sich auf FTP Server verbinden und der Verbindungsaufbau ist langsam?
Ganz genau, das Problem tritt sowohl bei Passiven als auch bei Aktiven verbindungen auf. Es geht ja auch nicht um den Datenkanal selbst der funktioniert bei beiden Varianten gut es gehr ledeglich um den Connect auf die Server. Leider habe ich das Problem bei allen VMs die mit Pfsense betrieben werden nicht nur bei mir sondern ZB auch auf OVH Virtuellen Server die auch mit ESXi und Pfsense arbeiten.
Man findet dazu auch jede menge im netz aber das problem wird dort nicht wirklich behoben.Ich habe testweise eine Linux VM installiert mit einem Squid Proxy ( läuft auch über pfsense ) und habe versucht über diesen schneller connecten zu können, leider genau das selbe ergebniss.
hier mal ein auszug des connects:
[1] Verbinde zu XXX IP:PORT <------ GENAU AN DIESER STELLE CA 8 SEKUNDEN WARTEZEIT [1] 220 Server <------ AB HIER GEHT ALLES FIX [1] AUTH SSL [1] 234 AUTH SSL successful [1] Verschluesselungs-Algorithmus: TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384-256 [1] USER XXX [1] 331 Password required for XXX. [1] PASS (versteckt) [1] 230 User XXX logged in. [1] SYST [1] 215 UNIX Type: L8 [1] PBSZ 0 [1] 200 PBSZ 0 successful [1] PROT P [1] 200 Protection set to Private [1] TYPE A [1] 200 Type set to A. [1] FEAT [1] 211 END [1] PWD [1] 257 "/" is current directory. [1] CWD /incoming/ [1] 250 CWD command successful. [1] PWD [1] 257 "/incoming" is current directory. [1] stat -l [1] Auflistung beendet: 1.842 bytes in 0,03s (59,42KB/s) -
Problem gelöst 113 (IDENT/AUTH) Port muss freigegeben und auf client weitergeleitet werden :)
-
Das ist dann aber der Verbindungsaufbau zum Zielhost. Normalerweise heißt das, dass das Ziel so lange braucht um zu antworten. Das kann ggf. daran liegen, dass das Ziel eine rDNS Auflösung versucht und scheitert, weil es keinen reverse Eintrag für die verbindende IP gibt. Wenn du das Ziel selbst kontrollieren würdest, könntest du das überprüfen, aber so wird das recht schwer sein. Es gibt auch nervigen Kram mit 113/identd der da ggf. reinspielt. Da gab es seinerzeit mal einen Auth Proxy der einfach zu allem immer ja gesagt hat, weil das Protokoll eigentlich kein Mensch mehr nutzt (und FTP ein uraltes und grausames Protokoll ist).
-
Hi Boecki,
das Problem wirst du dann aber bei jemden Client wieder haben.
Schalten den Ident Lookup am Server aus um einen schnelleren Verbindungsaufbau zu haben.
Bei Proftpd in der config:
IdentLookups offLG
-
Das hatte ich mit als erstes Versucht Wexxler hat aber auch nichts gebracht.
Is das denn ein problem auf mehreren clienten den Port 113 weiterzuleiten ? In der FritzBox zb kannst du einen Port nur 1x auf eine ip weiterleiten.
-
Nutzt du ProFTPD?
Füge noch
UseReverseDNS off
in die Config ein und schaue ob per Default diese beiden Parameter nicht weiter unten wieder auf on stehen.
-
Nein ich nutze Glftpd da sind solche settings leider nicht möglich :(.
Greife aber auch auf andere Ftp server zu wo ich keinen einfluss auf die settings habe. -
So habe es auf verschiedenen Clients getestet. Wieso auch immer aber es reicht den Port 115 1x auf eine Vm weiterzuleiten und das problem tritt auf keiner anderen VM mehr auf :D kann ich mir nicht erklären wieso aber die lösung ist optimal.
-
Na gut okay, andernfalls hätte ich nun gesagt versuche mal ob dir das package widentd weiterhilft - das sollte das Problem auch lösen.
Schalte die Kiste doch mal aus worauf der Port weitergeleitet ist, dann wird es wohl nicht mehr gehen auf den anderen kisten.
LG
-
Danke für eure Hilfe :) kaum ist das eine problem gelöst steht das nächste vor der Tür…..
Ich habe eine VM mit Debian 7 laufen unter anderem läuft auf der vm ein Squid 2.7 den ich auch in den NAT regeln eingetragen hab aber ich kann nicht mit squid kommunizeiren weder intern über 192.168.x noch extern über die Server IP.
Ich habe gelsesen das Pfsense einen eigenen squid proxy mitbringt aber ich bin neuling und traue mich nicht sorecht an pfsene dran.
Hat jemand auch ein squid auf einer linux vm laufen ?
-
Auf einer VM nicht aber mit einem debian ja.
Was genau musst willst du denn da wissen? Also was meinst du mit kommunizieren?
Funktioniert der Seitenaufbau über den Proxy nicht?
-
Nein gar nicht er kommuniziert gar nicht mit dem Proxy weder lokal von einer vm noch extern.
Proxy ist online
root@debian ~ > netstat -tulpe | grep squid
tcp 0 0 *:36688 : LISTEN root 504429 23219/(squid)
udp 0 0 *:31583 : proxy 506174 23219/(squid)Port 36688 ist in den NAT regeln auf die vm weitergeleitet.
-
Okay, dann wäre deine Config zu sehen wohl wertvoll.
Hast du eine acl src hinterlegt?
-
http_port 36688 icp_port 0 cache_mem 100 MB cache_dir ufs /home/squid/ 9000 16 256 ipcache_size 1000 quick_abort_min 0 KB quick_abort_max 0 KB quick_abort_pct 100 cache_store_log none cache_access_log /dev/null cache_log /dev/null logfile_rotate 5 auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/passwd acl ncsa_users proxy_auth REQUIRED acl all src 0.0.0.0/0.0.0.0 acl SSL_ports port 443 563 acl Safe_ports port 80 21 443 563 70 210 1025-65535 acl CONNECT method CONNECT #acl LAN1 src 192.168.0.0/255.255.0.0 http_access allow ncsa_users http_access allow !Safe_ports http_access allow CONNECT !SSL_ports #http_access allow LAN1 http_access allow ncsa_users http_access deny all -
Sieht soweit ja in Ordnung aus. Haste mal http_access allow all probiert was dann passiert? Vielleicht klappt ja das mit dem auth nicht
-
Bingo! Irgendwas war wohl mit den passwd file nicht in ordnung hab neuen user + pass erstellt und alles wunderbar :)
Danke für eure hilfe ;)
-
Nochmal eine frage wofür ich nicht extra einen Thread erstellen möchte.
Ich betreibe PFsense auf einer ESXi plattform nun habe ich gelesen das die VMware tools auch in Pfsense installiert werden können. Da aber bei mir mehrere vms laufen und ich nur ungerne restarten möchte ist die frage bringt es was die vmware tools auf pfsense zu installieren ?
-
Dafür muss nicht neu gestartet werden. Man kann einfach das Paket installieren, gestartet wird es dann automatisch. Es sind auch nicht die vmware-tools von VMware selbst, sondern die openvm tools. Sie sind aber ganz nützlich, damit vmWare oder ein VCenter bspw. Daten von der VM abfragen kann (Heartbeat, RAM, CPU etc.), insofern würde es schon Sinn machen sie zu installieren.
