[lvs-users] ip_vs_ftp and passive FTP: acknowledgement numbers from client not translated

Nick Chalk nick at loadbalancer.org
Thu May 17 12:03:17 BST 2012


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.

Attached is a packet capture demonstrating the problem. The test
configuration is as follows:
   Client:   192.168.64.3/18   (Linux)
   Loadbalancer:   Static IPs   eth0 192.168.67.21/18
                                               eth1 10.168.67.21/16
                             Virtual IP    192.168.110.67/18
   Real Server:   10.168.101.2   (Windows)

Running IPVS configuration:
   IP Virtual Server version 1.2.1 (size=4096)
   Prot LocalAddress:Port Scheduler Flags
     -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
   TCP  192.168.110.67:21 wlc
     -> 10.168.101.2:21              Masq    1      0          0

The test was simply to log in as anonymous, switch to passive mode,
and issue a LIST command.

Frames 33 and 34 show the server's response to the PASV command being
translated correctly. Frame 35 is the client's ACK response to the
load balancer, with (relative) Acknowledgement number 189. However,
frame 33 from the server has sequence number 137 and a length of 50
bytes, so it is expecting an acknowledgement of 187. The client
continues with setting up the data connection in frames 37 to 42, and
issues the LIST command. The server does not respond, but retransmits
the 227 response in frame 47. This sequence repeats until the real
server closes the connection.

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?

Thanks for your help.
Nick.

-- 
Nick Chalk.

Loadbalancer.org Ltd.
Phone: +44 (0)870 443 8779
http://www.loadbalancer.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ftp-nat-3.3.6-filtered.pcap
Type: application/cap
Size: 9994 bytes
Desc: not available
Url : http://lists.graemef.net/pipermail/lvs-users/attachments/20120517/823aa13d/attachment-0001.bin 


More information about the lvs-users mailing list