LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: [lvs-users] ip_vs_ftp and passive FTP: acknowledgement numbers from

To: Nick Chalk <nick@xxxxxxxxxxxxxxxx>
Subject: Re: [lvs-users] ip_vs_ftp and passive FTP: acknowledgement numbers from client not translated
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
From: Julian Anastasov <ja@xxxxxx>
Date: Fri, 18 May 2012 00:13:27 +0300 (EEST)
        Hello,

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
otherwise.

> 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
> ip6table_mangle,iptable_mangle,iptable_nat,ip6table_filter,ip6_tables,iptable_filter,ip_tables
>    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, 2.6.39.4, 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.
> 
> -- 
> Nick Chalk.
> 
> Loadbalancer.org Ltd.
> Phone: +44 (0)870 443 8779
> http://www.loadbalancer.org/

Regards

--
Julian Anastasov <ja@xxxxxx>

_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/

LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users

<Prev in Thread] Current Thread [Next in Thread>