|
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/
ftp-nat-3.3.6-filtered.pcap
Description: application/cap
_______________________________________________
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
|
