Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 35235 - ip_nat_ftp appears not to work
ip_nat_ftp appears not to work
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: David Miller
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2001-04-08 14:12 EDT by Jay Berkenbilt
Modified: 2007-04-18 12:32 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-04-10 12:50:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jay Berkenbilt 2001-04-08 14:12:58 EDT
With the most recent rawhide kernel and modutils:

# rpm -qa | egrep '(kernel|modutils)'

# cat /proc/version
Linux version 2.4.2-0.1.49 (root@porky.devel.redhat.com) (gcc version 2.96
20000731 (Red Hat Linux 7.1 2.96-79)) #1 Sun Apr 1 15:58:50 EDT 2001

I am unable to get ftp masquerading to work properly.  I believe this has
been true at least since 2.4.1-0.1.9 but I can't say for sure whether it
worked before.

With the following iptables configuration:

# cat /proc/net/ip_tables_names

# iptables -t nat -L -n
target     prot opt source               destination         

target     prot opt source               destination         
SNAT       all  --         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
# iptables -t filter -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --          
ACCEPT     all  --            state

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

and the following modules loaded:
# lsmod
Module                  Size  Used by
ip_nat_ftp              3760   0  (unused)
ipt_state               1200   1  (autoclean)
iptable_nat            16160   1  (autoclean) [ip_nat_ftp]
ip_conntrack           15824   2  (autoclean) [ip_nat_ftp ipt_state
iptable_filter          2304   0  (autoclean) (unused)
ip_tables              11072   5  [ipt_state iptable_nat iptable_filter]
ide-scsi                8352   0 
scsi_mod               95040   1  [ide-scsi]
autofs                 11264   1  (autoclean)
de4x5                  41776   1 
via-rhine              10880   1 

if I use active mode ftp from a machine behind this firewall to a machine
on the outside, the PORT command's IP address is not rewritten (i.e., my
private, non-routable IP address is exposed).  Passive mode ftp and other
protocols that don't include IP addresses in the data stream work fine.

I have been using ftp masquerading with 2.2 kernels for ages.

I posted a question about this to the wolverine list but got no replies.  I
can't promise I'm not making a mistake somewhere, but I feel compelled to
post this bug report so that it gets into the system in case this really is
broken!  I entered this as high severity because I know of no workaround.

In case it's easier to see my configuration this way, here's my setup:

iptables -t filter -P FORWARD DROP
iptables -t filter -A FORWARD -s -j ACCEPT
iptables -t nat -A POSTROUTING -s -j SNAT --to-source
iptables -t filter -A FORWARD -m state --state ESTABLISHED,RELATED -j

modprobe ip_nat_ftp

Is there really a problem with ip_nat_ftp, or am I doing something wrong? 
What else should I do to debug this?  In the absense of other suggestions,
I will probably compile a debugging version of this module.  I am certain
that the PORT rewriting is not happening as I can run strace on the ftpd on
the server.  When I boot into RedHat 7.0, the rewriting happens; when I
boot into wolverine (well, actually fisher with lots of wolverine upgrades
applied including kernel and modutils from the latest up2date run), it
Comment 1 Arjan van de Ven 2001-04-08 14:24:06 EDT
Dave: do you have time to take look at this ?
Comment 2 Jay Berkenbilt 2001-04-10 12:50:18 EDT
Never mind -- you also need to load ip_conntrack_ftp.  I'll let someone else
mark this as NOTABUG in case it should have happened automatically somehow
though I doubt that.

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