Hide Forgot
**Description 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. **Observed Behavior The ftp client reports: ftp: connect: No route to host. and the file is not transferred. **Expected Behavior The file should have been transferred. **Additional Information 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 to FC5. Please retest with Fedora Core 5. Thank you.
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. Thank you.
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. Thank you.