On Fri, 25 Nov 2005, Mark de Vries wrote:
Problem found...
The thing is that ip_vs(_ftp) seems to assume that the
ftp-data connection will be initiated from port 20. Seems
like a valid assumption...
But unfortunately this is not always the case... the
vsftpd I was testing with was configured to
"connect_from_port_20=NO" by default. Once I swithched to
"=YES" active FTP worked fine.
good sleuthing
"connect_from_port_20=NO":
IPVS: PORT 10.31.12.172:32847 detected
IPVS: Bind-dest TCP c:10.31.12.172:32847 v:10.31.7.250:20 d:10.0.0.100:20 fwd:M
s:0 flg:100 cnt:1 destcnt:5
IPVS: lookup/out TCP 10.0.0.100:32774->10.31.12.172:32847 not hit
"connect_from_port_20=YES":
IPVS: PORT 10.31.12.172:32849 detected
IPVS: Bind-dest TCP c:10.31.12.172:32849 v:10.31.7.250:20 d:10.0.0.100:20 fwd:M
s:0 flg:100 cnt:1 destcnt:5
IPVS: lookup/out TCP 10.0.0.100:20->10.31.12.172:32849 hit
IPVS: After SNAT: TCP 10.31.7.250:20->10.31.12.172:32849
IPVS: TCP output [..A.] 10.0.0.100:20->10.31.12.172:32849 state:
SYN_RECV->ESTABLISHED cnt:2
So.... Now the question is: is this a vsftpd 'problem'?
MUST ftp-data connections originate from port 20? Or
should this assumption be relaxed?
Aparently the iptables contrack_ftp module does not assume
it; Connections from ports other then 20 are considered
"RELATED". (I have not checked the src or debugged
anything, I just observed that this type of connection is
indeed matched by a "RELATED" rule in my own iptables
setup.)
the ftp helper was written in the early 2.4 kernel days and
I doubt if it's had much attention since then. Presumably it
was the easiest code to get going and since there were no
problems for 5 years (or however long it's been), everyone
has forgotten about the data port. Are you up for adding a
--data-port="some_number" option to the code?
Joe
--
Joseph Mack NA3T EME(B,D), FM05lw North Carolina
jmack (at) wm7d (dot) net - azimuthal equidistant map
generator at http://www.wm7d.net/azproj.shtml
Homepage http://www.austintek.com/ It's GNU/Linux!
|