Bug 48767 - FTP data connection comes back with real IP address in FTP data connection instead of virtaul address.
Summary: FTP data connection comes back with real IP address in FTP data connection in...
Alias: None
Product: Red Hat High Availability Server
Classification: Retired
Component: piranha   
(Show other bugs)
Version: beta
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Tom "spot" Callaway
QA Contact: Phil Copeland
Keywords: Security
Depends On:
TreeView+ depends on / blocked
Reported: 2001-07-11 15:19 UTC by Need Real Name
Modified: 2007-04-18 16:34 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-10-10 17:34:30 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
lvs.cf file (837 bytes, patch)
2001-07-16 14:52 UTC, Need Real Name
no flags Details | Diff
ipvsadm-1.18-8 (790.96 KB, application/x-rpm)
2001-10-10 17:16 UTC, Tom "spot" Callaway
no flags Details
scsi_reserve-0.7-5.src.rpm (for real. :) (29.88 KB, application/x-rpm)
2001-10-10 17:19 UTC, Tom "spot" Callaway
no flags Details
ipvsadm-1.15-1.src.rpm (honestly, it is. use this for kernel 2.2.X) (28.83 KB, application/x-rpm)
2001-10-10 17:34 UTC, Tom "spot" Callaway
no flags Details

Description Need Real Name 2001-07-11 15:19:26 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows 98; NetCaptor 

Description of problem:
When a user, behind their firewall, ftp through the high avaliblity server 
to one of the ftp servers using active ftp, he connects with no problems.  
But when he issuses a FTP command, the users remote firewall rejects the 
request because it comes from the high availbilty servers's real ip 
address and not the virtual servers's address.
I am using NAT with a master and backup piranha server with 3 backend FTP 
servers that handle the data.
For example: 
Virtual address:, Real address:
User ftp to, connects fine, issue a ls command (not in 
passive mode since users computer does not support passive), data 
conection is opened back to the client but it comes from the .171 (real) 
address and the .170 (virtual) address.  Clients firewall rejects the 
request since it is a differnt IP address.  

Using most recent expermental server.

How reproducible:

Steps to Reproduce:
1. ftp
2. disable passive (if coming from computer which supports it)
3. Issue any command like ls

Actual Results:  Data connection comes back from IP address of (real pirahna server)

Expected Results:  Data connection comes back from IP address of (virtual ip address, what the firewall expects.

Additional info:

Using latestes experminatl server.
Using redhat 6.2 with all updates.

Put severtiy at security issue since client has to open up all high TCP 
ports in from the real address which opens their site up.

Comment 1 Phil Copeland 2001-07-11 18:16:57 UTC
Humm I suspect you havn't got persistance enabled for the virtual server (no
config file to look at so this is a guess). The experimental rpms offer a
facility on the virtual service

Persistance (time in seconds a connection to this machine should contine to go
to that machine for ftp the normal timeout is 900 seconds so this would be a
good value to place here)

Persistance netmask (should normally be


Comment 2 Need Real Name 2001-07-16 14:52:52 UTC
Created attachment 23707 [details]
lvs.cf file

Comment 3 Need Real Name 2001-07-16 14:57:06 UTC
Since submitting this bug, I have tried to use iproute2 in order to change the 
source routing for the master.  This has work a little but I still have 
problems with this.  First, I have not found a way to when the backup to the 
master to take over, how to enter the iproute2 command.  Second, if I did find 
a way to put the command in, I would also need a way to take the command out 
when the master server comes back on line.

Another problem I found with this is that the source port for the data 
connection is not port 20, it is a high TCP port, so the remote firewall still 
rejects it after the IP address has been changed.

Comment 4 Need Real Name 2001-07-16 14:59:03 UTC
Another note is that persistance time out has no effect on this problem.  This 
is not a timeout problem at all.  It is a routing and port problem.

Comment 5 Tom "spot" Callaway 2001-08-20 21:53:52 UTC
This is definitely a routing and port problem, and its due to the limitations of
ipchains, which is what piranha is using to create its LVS routes. The obvious
solution would be to redo piranha to implent netfilter/iptables so that both
passive and active ftp connections could be supported, instead of the current
"one or the other" scenario. However, while this is a good long-term goal, its
unlikely that this change will be made anytime soon.

Comment 6 Tom "spot" Callaway 2001-10-10 17:15:17 UTC

Network topology. In this example, I have the two Piranha
nodes off the main network.  Their "outer" network is 
The ftp servers are on an "inner" network (  

Piranha configuration (both nodes):
  Configured for LVS and NAT routing.  
  The virtual ftp service is configured to use firewall mark 21 (the
actual number used shouldn't matter), and has a persistence of 120

FTP server configuration (same for all):
  The ftp servers must be configured to report the appropriate hostname
for passive ftp connections and to limit the ports used for those
connections.  You can do this by editing /etc/ftpaccess and adding the
following lines:
     passive address
     passive ports 10000 20000  
This says to the ftp server: "For clients in the netmask report my hostname as and use only ports
10000 to 20000 for passive connections."  A range of 10000 ports is
probably overkill, but keep in mind that with persistent connections,
there may be many ports in use at once.
  See also the man page for ftpaccess.

ipchains configuration (on piranha nodes):
  Piranha is looking for marked packets, so we must provide the marks. 
You'll want to mark all incoming packets to ports 21 and 10000 to 20000. 
The ipchains commands I used for this were:
ipchains -F
ipchains -A input -i eth0 -p tcp -d 21 -m 21
ipchains -A input -i eth0 -p tcp -d 10000:65535 -m 21
  Note that the mark matches the one piranha is looking for and the port
range matches the one the ftp servers were configured to use.
---Sample lvs.cf:--------------------------------------
serial_no = 334
primary =
primary_private =
service = lvs
backup_active = 1
backup =
backup_private =
heartbeat = 1heartbeat_port = 539
keepalive = 6
deadtime = 18
network = nat
nat_router = eth1:0
nat_nmask =
reservation_conflict_action = preempt
debug_level = NONE
virtual lvs_ftp {
     active = 1
     address = eth0:1
     vip_nmask =
     fwmark = 21
     port = 21
     persistent = 120
     send = "quit\n"
     expect = "220"     load_monitor = rup
     scheduler = rr
     protocol = tcp
     timeout = 6
     reentry = 15
     server [unnamed] {
         address =
         active = 1
         weight = 1
     server [unnamed] {
         address =
         active = 1
         weight = 1
     server [unnamed] {
         address =
         active = 1
         weight = 1
---end of sample lvs.cf--------------------------------------

You'll need to --rebuild the attached srpms and upgrade to those in order to use
this workaround.

Comment 7 Tom "spot" Callaway 2001-10-10 17:16:57 UTC
Created attachment 33781 [details]

Comment 8 Tom "spot" Callaway 2001-10-10 17:19:04 UTC
ok. thats not really ipvsadm-1.18-8. its piranha-0.6.0-8.src.rpm. this is what i
get when i try to multitask. :)

Comment 9 Tom "spot" Callaway 2001-10-10 17:19:53 UTC
Created attachment 33782 [details]
scsi_reserve-0.7-5.src.rpm (for real. :)

Comment 10 Tom "spot" Callaway 2001-10-10 17:34:26 UTC
Created attachment 33783 [details]
ipvsadm-1.15-1.src.rpm (honestly, it is. use this for kernel 2.2.X)

Comment 11 Phil Copeland 2001-10-10 18:22:35 UTC
Actually it's all built out of the errata system and available externally on

6.2 is 2.2 based and the last release of ipvsadm for that kernel was 1.15-1
7.2 when it *really* gets released uses version 1.18 and above but is not
compatible with a 2.2 kernel


Note You need to log in before you can comment on or make changes to this bug.