Hello. My organization has been using PASV FTP via VSFTPD for some time now. We have defined the port range between 30000 and 33333 and as I mentioned, it has worked up to 20100108 (last Friday).
It appears that VSFTPD is not negotiating the defined PASV port range, which we can see with both netstat and tcpdump.
Has anyone here run into this before? Are there any VSFTPD hackers out there who know what mechanism VSFTPD is using to re-allocate the ports? I would think that it would release the port, and flag it as unused, or something...
Thanks in advance,
A

Lets start with the traditional question - what's changed ?

- check the modified date on your vsftpd.conf
- when was the vsftpd process started ?
- has vsftpd been updated ? .. when ?
- have there been any firewall changes/updates ?
- are the failing connections from a single source or multiple ?

cheers

Sorry, I could have probably avoided the obvious questions with:
Nothing was changed in vsftpd
No firewall changes
No network changes
I've modified vsftpd.conf quite a few times today (adjusting min_pasv_port and max_pasv_port)
All ACTIVE connections work, only PASV fails
We can see via every tool available, that vsftpd is not using the defined PASV port range, but is choosing incrementally higher port numbers for each connection. This appears to be why it has worked up until last Friday; we hit port # 333334 (our max_pasv_port is set to 33333).
Our firewall has 30000-33333 open for this particular reason.

Thanks
A

Aren't they supposed to be

not

?

Uh, yea, my typo (in the post, not the config).
As it turns out, it never should have been working in the first place. We worked on it till the wee hours of the night, and the solution turned out to be as strange as it having been working in the first place.
The history (just in case another sad SA has to tackle this thing at some point):
This configuration at the onset worked perfectly:
(sans things I don't want to share...)
pasv_enable=yes
pasv_min_port=30000
pasv_max_port=33333
pasv_address=external.ftp.server.ip
port_enable=YES
use_localtime=YES
anonymous_enable=NO
local_enable=YES
user_sub_token=$USER
local_root=/home/ftpHomes/$USER
write_enable=YES
anon_upload_enable=YES
anon_mkdir_write_enable=YES
anon_other_write_enable=YES
chroot_local_user=YES
guest_enable=YES
guest_username=ftpuser
listen=YES
listen_port=21
pam_service_name=vsftpd
hide_ids=YES
log_ftp_protocol=YES
xferlog_enable=YES
local_umask=0022
anon_umask=0022
ssl_enable=YES
allow_anon_ssl=NO
force_local_data_ssl=YES
force_local_logins_ssl=NO
rsa_cert_file=/etc/vsftpd/vsftpd.pem
use_sendfile=NO
connect_from_port_20=YES
listen=yes


Very soon after successfully testing this configuration, we began sending traffic to this working config and then suddenly one day, PASV suddenly stopped working. As we had no control over the network any longer (our small company was acquired by a large corporation), certain changes and restrictions were made to the firewall, which made it necessary to add the PASV ranges, and strangely enough, remove the pasv_address= declaration. This should not have worked, but it did for some reason. Like I said, there are definitely things outside my control which appear to change, though the network guys will always claim that no changes had been made.
At any rate, we removed the load-balancer from the equation to eliminate the possibility of it mangling the packets and whatnot, but this didn't prove to do any good, so I set the config back to the original, and what do you know; it works again.

So that is my saga of how VSFTP+Corporate Networks == Shiat-That-Makes-Me-Pull-All-Nighters.

Ciao