All users get blocked when FTP
I recently migrated all users on one of my RHEL servers to a new CL 6.7 server with CSF/LFD installed, and now they all get blocked in the firewall when connecting via FTP.
I've been using the same CSF/LFD settings on my RHEL servers for years, no issues, with the following important settings:
PassivePortRange 30000 35000 is set in /etc/pure-ftpd.conf
30000:35000 is allowed in CSF TCP_IN
I've made all of my CSF/LFD config settings on the CL box virtually identical to my CSF/LFD settings on my RHEL boxes.
All servers are running cPanel 54 (release), Pure-FTPD, PHP 5.5 native, MySQL 5.5, suPHP
KernelCare is running on the CL box and LVE Manager and CL are kept updated.
/var/log/messages is a steady stream of users getting blocked like this:
I've been chasing this issue down for days and I can't seem to find an answer anywhere I look, other than people saying to not use CSF. I've relied on CSF/LFD for years and don't ever wish to give it up. Plus it works perfectly with RHEL and never any problem with FTP blocking users. Has anyone here encountered this and found a solution? At this point I'd practically donate a kidney to resolve this. Thank you to anyone who takes a minute to respond.
Feb 7 08:10:09 hostname kernel: [632812.934208] Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=0c:c4:7a:47:04:b0:00:08:e3:ff:fe:bc:08:00 SRC=xxx.xxx.xxx.xxx DST=xxx.xxx.xxx.xxx LEN=64 TOS=0x08 PREC=0x40 TTL=50 ID=27457 DF PROTO=TCP SPT=57348 DPT=585 WINDOW=65535 RES=0x00 SYN URGP=0
Feb 7 06:06:08 hostname kernel: [625365.894691] Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=0c:c4:7a:47:04:b0:00:08:e3:ff:fe:bc:08:00 SRC=xxx.xxx.xxx.xxx DST=xxx.xxx.xxx.xxx LEN=52 TOS=0x00 PREC=0x00 TTL=117 ID=21468 DF PROTO=TCP SPT=60678 DPT=43884 WINDOW=65535 RES=0x00 SYN URGP=0
Feb 7 05:30:19 hostname pure-ftpd: (?@xxx.xxx.xxx.xxx) [INFO] user is now logged in
Feb 7 05:30:20 hostname kernel: [623216.877561] Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=0c:c4:7a:47:04:b0:00:08:e3:ff:fe:bc:08:00 SRC=xxx.xxx.xxx.xxx DST=xxx.xxx.xxx.xxx LEN=52 TOS=0x08 PREC=0x40 TTL=116 ID=25741 DF PROTO=TCP SPT=57322 DPT=36337 WINDOW=65535 RES=0x00 SYN URGP=0
I've been chasing this issue down for days and I can't seem to find an answer anywhere I look, other than people saying to not use CSF. I've relied on CSF/LFD for years and don't ever wish to give it up. Plus it works perfectly with RHEL and never any problem with FTP blocking users. Has anyone here encountered this and found a solution? At this point I'd practically donate a kidney to resolve this. Thank you to anyone who takes a minute to respond.
-
Have you tried turning on "Broken Clients Compatibility" in WHM > Service Configuration > FTP Server Configuration? Will be interested to know what you eventual find solves the problem. 0 -
Thanks for the reply, and yes I had to enable Broken Clients Compatibility early on when I first got this new server provisioned back in December, as you can see where I posted about that here - Pure-Ftpd Not Working on cPanel 11.52 Another thing I've tried is disabling CageFS for a user and had them test, and still no joy. I did discover something that might prove to be useful just a few minutes ago: One of my users was on the phone with me a few minutes ago and he can FTP to his Addon Domains with no problem and doesn't get blocked. It's only his master account FTP connection that gets blocked. I'm also looking at the possibility that this may be mostly affecting users on dedicated IP addresses, but that is still up in the air at the moment because most of my users who use FTP frequently are businesses with e-commerce and dedicated IP's for the SSL cert purposes. I'm still stumped though, and running out of steam and probably headed toward ending up in the hospital... 0 -
I have only two short things to say before I go pass out: 1. My stupid oversight! Time for glasses and a lower resolution screen for this old man. /etc/pure-ftpd.conf had 30000 50000, not 30000 35000 :oops: :mad: 2. The folks at ConfigServer Services are incredibly awesome! 0 -
The folks at ConfigServer Services are incredibly awesome!
No doubt about that.0 -
Edit /etc/pure-ftpd.conf and make sure PassivePortRange is set to the same range you have open in your firewall. This is the most common cause of this problem, where users can connect via FTP but get disconnected whenever they try to open a folder or really do anything else. 0 -
. My stupid oversight! Time for glasses and a lower resolution screen for this old man. /etc/pure-ftpd.conf had 30000 50000, not 30000 35000 :oops: :mad:
Hello :) I am happy to see you were able to address the issue. Note there's a guide on this at: How to Enable FTP Passive Mode - cPanel Knowledge Base - cPanel Documentation Thank you.0 -
Thanks, but that's the thing - How to Enable FTP Passive Mode - cPanel Knowledge Base - cPanel Documentation states to use 30000 50000 and that was the problem. Once changed to 30000 35000 the problem is resolved. (And all of my other servers are 30000 35000, and I thought this new one was too, but either one of the DC techs set the higher to 50000 on this particular box or I did and didn't remember, but anyway 30000 35000 is what works on all my boxes). 0 -
Just a minor little followup on this... As it turns out, on these new CloudLinux 6.7 servers (at least the ones I recently purchased)... ANY time any setting is changed at all in WHM > Service Configuration > FTP Server Configuration, or even if no change is made but you click the Save button in WHM > Service Configuration > FTP Server Configuration It automatically resets PassivePortRange to 30000 50000 in /etc/pure-ftpd.conf So, if you're an "old schooler" who has always had it set 30000 35000 in /etc/pure-ftpd.conf and 30000:35000 in your CSF TCP_IN field, then this little bugger will, for lack of a better term - mess with you! For many years it seemed the standard was always 30000:35000 (which you'll also see commonly posted in places like the FileZilla forums) so once you set it in your CSF and pure-ftpd.conf you could forget it, even when making other changes in WHM > Service Configuration > FTP Server Configuration. But now, at least with these new CL servers I got, any time the Save button is clicked in WHM > Service Configuration > FTP Server Configuration for any reason at all, it automatically resets PassivePortRange to 30000 50000 in /etc/pure-ftpd.conf I learned the hard way this morning when after making a slight change to a different setting in WHM > Service Configuration > FTP Server Configuration last night, suddenly this morning noticed users getting blocked for "port scans" just for logging in to FTP. So instead of trying to fight it and do things the way I always have for years (30000:35000) I just changed my CSF TCP_IN to include 30000:50000 so it'll never require a second thought if I ever have change a setting in WHM > Service Configuration > FTP Server Configuration again. On the one hand I guess this seems a bit silly on my part, but on the other hand I feel at least tiny bit vindicated since in the end it was an issue of the WHM FTP Server Configuration tool changing PassivePortRange back to 30000 50000 in /etc/pure-ftpd.conf after I'd already gone in to /etc/pure-ftpd.conf and setting it to 30000 35000. What I thought was just my tired eyes making an oversight was really that setting being changed without my knowledge when I was making a completely different adjustment in WHM FTP Server Configuration. I hope at least this little merry go 'round I got stuck on ends up helping someone else someday. o_O 0 -
WHM FTP Server Configuration tool changing PassivePortRange back to 30000 50000 in /etc/pure-ftpd.conf after I'd already gone in to /etc/pure-ftpd.conf and setting it to 30000 35000.
It's important to note that changes to the FTP configuration file via the command line should be made in /var/cpanel/conf/pureftpd/main as opposed to /etc/pure-ftpd.conf to ensure the changes are permanant:0 -
Thank you cPanelMichael! That info came in very handy, especially the rm -f /var/cpanel/conf/pureftpd/main.cache and /scripts/setupftpserver pure-ftpd -"force which I'd forgotten all about since it's been so long since I've needed to use them. I totally needed this reminder! 0 -
Thank you of this infomation. 0
Please sign in to leave a comment.
Comments
11 comments