When using passive ftp, I can successfully transfer files using passive mode
ftp from an FC4 server to an FC4 client (also 2.6.14-1.1656_FC4smp with
ip_conntrack_ftp loaded). If, however, the same client connects to the same
server over an IPSec tunnel, the ftp session fails transferring the same file
and produces the following error message:
ftp: connect: No route to host.
Both the client and the server are running kernel 2.6.14-1.1656_FC4smp, and
both have ip_conntrack_ftp loaded.
**Steps to Reproduce
1. Install vsftp on FC4 server. Install iptables firewalls on both client and
server. Load ip_conntrack_ftp on server. Poke holes in firewalls for ftp.
Confirm proper operation of ftp passive mode.
2. Build IPSec tunnel between FC4 server and FC4 client (NAT, Kame/racoon, pre-
shared keys, ESP). Add iptables rule ACCEPTing all forwarded traffic between
server and client. Confirm proper operation of tunnel with many, many other
protocols and months of observation.
3. transfer file from client to server using standard ftp command line utility.
4. Attempt to transfer same file from client to server in same fashion, but
specify the server's IP address such that a direct connection is used instead
of the IPSec tunnel.
The ftp client reports:
ftp: connect: No route to host.
and the file is not transferred.
The file should have been transferred.
If I immediately unload iptables on the ftp server and again attempt the
transfer, everything works beautifully.
This problem is VERY similar to Bugzilla 172845. Both are examples of
iptables helper modules failing to work over and IPSec tunnel but working
perfectly across a standard link.
Unfortunately, the only workaround (in both cases) is to transmit in the clear
or disable the firewall.
Assigning to kernel - iptables is the userland configuration tool.
[This comment added as part of a mass-update to all open FC4 kernel bugs]
FC4 has now transitioned to the Fedora legacy project, which will continue to
release security related updates for the kernel. As this bug is not security
related, it is unlikely to be fixed in an update for FC4, and has been migrated
Please retest with Fedora Core 5.
A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.
Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.
This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.
Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.
In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed. See bug 207474 for further details.
If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.
If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.
This bug has been mass-closed along with all other bugs that
have been in NEEDINFO state for several months.
Due to the large volume of inactive bugs in bugzilla, this
is the only method we have of cleaning out stale bug reports
where the reporter has disappeared.
If you can reproduce this bug after installing all the
current updates, please reopen this bug.
If you are not the reporter, you can add a comment requesting
it be reopened, and someone will get to it asap.