[Bug 1164] New: FTP NAT fails in a specific scenario after upgrade to kernel 4.7+

[bugzilla-daemon at netfilter.org]

https://bugzilla.netfilter.org/show_bug.cgi?id=1164

            Bug ID: 1164
           Summary: FTP NAT fails in a specific scenario after upgrade to
                    kernel 4.7+
           Product: netfilter/iptables
           Version: unspecified
          Hardware: x86_64
                OS: Fedora
            Status: NEW
          Severity: normal
          Priority: P5
         Component: NAT
          Assignee: netfilter-buglog at lists.netfilter.org
          Reporter: br.larini at gmail.com

After upgrading from kernel 4.6.5-300.fc24.x86_64 to 4.10.10-100.fc24.x86_64 I
can't estabilish FTP connections that are originated in my LAN to an FTP
server, also located in the LAN. The distro is Fedora 24 and the kernel are
from official repositories.

- My firewall server DNATs FTP connections on port 21 to a server inside the
LAN listening on port 2121. 
- External clients can connect to the FTP server normally.
- When these same clients are inside the LAN, the connections are also DNATted
because they are still using the saved config in their FTP client software
(that is, the public IP address). An additional SNAT rule needed to be added so
the FTP server won't try to communicate with the client directly, as both are
in the same network. This works as expected.
- In my current working config, I'm using "nf_conntrack_helper=1" (even knowing
that on 4.6 it wasn't really necessary).

After upgrading to 4.10.10-100.fc24.x86_64 this stopped working *only when the
FTP connection originates from the LAN*. Users outside can browse it normally.

I'm now aware that there were changes regarding the NAT helpers after 4.7 and
tried to make changes according. Now I have the following:

- Set "nf_conntrack_helper=0".
- Removed the "options nf_conntrack_ftp ports=21,2121" from modprobe.
- Added to my ruleset: "iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT
--helper ftp". In my tests, added one for 2121 too.

With this I'm stuck in the same part I was before making these changes: it
works for external clients but not for internal ones. I suppose that's because
the old way is still supported.

What I noticed: ports defined to use the FTP helpers don't even finish the
control channel (again, only for internal clients). If the line with the helper
above is removed, it finishes the control channel but fails to estabilish the
data channel as expected.

In the past week I posted this problem on netfilter mail list to see if it
maybe was a mistake on my part, but couldn't get a solution for this.

Considering that this ruleset worked as desired on 4.6 and stopped in 4.7+,
even after applying the necessary changes, I supposed this could be filed as a
bug on the FTP helper.

Furthermore, I just tried it on Debian Stretch, kernel 4.9.0-3-amd64 and the
results were the same.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20170726/607eda0f/attachment.html>