Slow FTP and SFTP
-
I'm struggeling with a strange problem - when uploading from both FTP, FTPS and using SSH (SFTP), the uploads goes in small chunks and it is really lagging. Like one second, it transfer 20 files, in next moment, it just stands there for several seconds and seems to wait, before it transfers maybe 2 files and stops again before it continues and with some luck it transfers 20-25 files at great speed. For a long time, I have kind of ignored it. But now I want to fix it, as it is very annoying. One big file goes better.
What I can say for sure: This has nothing to do with the servers (as it happens on both physical and virtual servers - Linux and Windows). When transfering local on data center network, it goes really fast as it should.
- I don't notice it duing RDP and transfers through other channels.
- I don't have any intrusion detection on the fw.
- Tried an accept-all-ports, on top of the fw-list, to be sure nothing port-wise is stopping it. No change.
It is almost like it is slow because files are scanned and finally accepted for some seconds, but I don't have any IPS running. Maybe some kind over trigger happy dos-protection or a setting I migth have done wrong?
I have really simple network now, with static IPs on the data center side. Webservers, mail etc. works good.
Any idea where to start looking?
Packages:
pfBlockerNG, bandwidthd, iperf, nmap, ntopng, openvpnI'm running LACP lag on the LAN side (with switch support) - maybe this is related. I see it switches between those two every few second, sometimes it takes 10 seconds. Related?
-
@fireix If you mean uploading from internet wan to lan, just place a test ftp server connected directly on wan side and test your uploading again!
Without pfsense on "middle", so you can figure it out where you problems live. 
-
It's no problem uploading to the WAN side of this, before pfSense. Then it is just like the LAN-side, really fast. So something in pfSense is stopping this. Also, the speed is really good if I just upload a single file, then it goes like 20 Mbit and the upload isn't interupted at all. So small files are disaster, big files no problem.
-
@fireix It's simple enough make your way over "debugging", pfsense offer some tools and one-click-checkbox for starting to isolate "bad" component of the system.
First of all, if you suspect some bad interactions with LACP configuration, simple disable it and test again.
Same logic is applicable to others component like firefall, for disable it, just go to System / Advanced / Firewall & NAT and check Disable Firewall for a short test only, because this disable all packet filtering and NAT , remember to restarting after save and apply this.Well if no one of this is the trouble, maybe you need to check link flow stability by using some kind of tools like Packet capture or Wireshark on separate host connected to a switch lan port "in mirroring" mode with your pfSense lan port or with your ftp server port, to figure it out, maybe you can install wireshark directly on your ftp server, I dont'know.
Good luck!
-
@fireix said in Slow FTP and SFTP:
I'm running LACP lag on the LAN side (with switch support) - maybe this is related. I see it switches between those two every few second, sometimes it takes 10 seconds. Related?
Yeah turn that off.. Test it.
With that still off, if your still seeing problem then yes do capture of the traffic - you can do it right on pfsense... Look to see what is going on.
Here is the thing.. Pfsense has no clue if the data is RDP or FTP... Its just a packet.. It passes it or doesn't pass it based upon states and firewall rules.. If your not doing any sort of shaping/limiting pfsense going to move that traffic same as any other traffic..
You do understand moving lots of small files vs 1 large file is going to be different no matter what protocol your using to send the data.. SMB, FTP, AFS, NFS...
-
Indeed, files transfers of small size is always slower than bigger one.
(Check for example usb to sata transfers is same stuff of lan to sata, in terms of what filesystem need to do for storing thousands small files instead of bigger one.)
I'm agree with @johnpoz said of course.
bye.
