[lvs-users] ip_vs_ftp and passive FTP: acknowledgement numbers from client not translated
ja at ssi.bg
Thu May 17 22:13:27 BST 2012
On Thu, 17 May 2012, Nick Chalk wrote:
> Afternoon all.
> We have come across an interesting problem with the ip_vs_ftp module
> when using passive FTP.
> It appears to only manifest when the length of the virtual IP, in
> string form, is different from the length of the real server's IP.
> ip_vs_ftp correctly translates the "227 Entering Passive Mode"
> response from the real server, rewriting the latter's IP with the
> virtual IP and modifying the packet length accordingly. The client
> ACKs this packet, using the translated packet length to calculate the
> Acknowledgement number.
> However, IPVS passes the ACK packet on to the real server unchanged,
> so that the server receives an Acknowledgement number that it is not
> expecting. In our tests, it appears that the ACK is dropped, with the
> result that the FTP daemon does not see the response.
In my tests I'm doing exactly the same: RIP is
2 bytes shorter to catch such problems with SEQs.
And it works in many kernels.
There is a requirement ip_vs_ftp to work with
nf_conntrack_ftp and iptable_nat present. I don't see
the nf_conntrack_ftp in your module list. May be the
problem is that we do not specify that IP_VS_FTP
depends on NF_CONNTRACK_FTP in Kconfig.
ipv4_confirm() requires a NF helper to run on that
port (21), the seq adjusting code is not considered
> The loaded modules look to be correct:
> Module Size Used by
> ip_vs_wlc 1325 1
> ip6table_mangle 1219 0
> iptable_mangle 1184 0
> iptable_nat 3211 0
> ip6table_filter 1059 0
> ip6_tables 14757 2 ip6table_mangle,ip6table_filter
> iptable_filter 1088 0
> ip_tables 13597 3 iptable_mangle,iptable_nat,iptable_filter
> x_tables 13421 7
> ip_vs_ftp 6626 0
> ip_vs 135733 5 ip_vs_wlc,ip_vs_ftp
> nf_nat 12116 2 iptable_nat,ip_vs_ftp
> nf_conntrack_ipv4 9522 3 iptable_nat,nf_nat
> nf_conntrack 47424 4 iptable_nat,ip_vs,nf_nat,nf_conntrack_ipv4
> nf_defrag_ipv4 1083 1 nf_conntrack_ipv4
> There are no firewall rules in place on the load balancer.
> This behaviour has been observed with kernels 2.6.35, 188.8.131.52, and
> 3.3.6; the packet capture is taken from the last. The same result is
> seen when using a Linux real server.
> Also of interest is that the retransmissions of the 227 server
> response are not being translated.
> Are we missing something in the load balancer configuration?
Please try with nf_conntrack_ftp loaded.
> Thanks for your help.
> Nick Chalk.
> Loadbalancer.org Ltd.
> Phone: +44 (0)870 443 8779
Julian Anastasov <ja at ssi.bg>
More information about the lvs-users