bugzilla-daemon at netfilter.org
2017-Jul-26 19:59 UTC
[Bug 1164] New: FTP NAT fails in a specific scenario after upgrade to kernel 4.7+
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>
bugzilla-daemon at netfilter.org
2017-Jul-26 20:01 UTC
[Bug 1164] FTP NAT fails in a specific scenario after upgrade to kernel 4.7+
https://bugzilla.netfilter.org/show_bug.cgi?id=1164 Bruno <br.larini at gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |br.larini at gmail.com -- 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/3dba78f8/attachment.html>
bugzilla-daemon at netfilter.org
2017-Oct-30 13:25 UTC
[Bug 1164] FTP NAT fails in a specific scenario after upgrade to kernel 4.7+
https://bugzilla.netfilter.org/show_bug.cgi?id=1164 --- Comment #1 from Bruno <br.larini at gmail.com> --- Giving some feedback about this issue, it seems it got fixed in kernel 4.13. Strangely, no feature regarding any netfilter component was reported in the changelog (https://kernelnewbies.org/Linux_4.13). My ruleset which worked on 4.6, stopped up to 4.12 and now it's working again on 4.13 wasn't changed a single line (apart from updating the correct use of helpers, but that was tested and worked on 4.6 too). So, booting on 4.13.9-200.fc26.x86_64 it works, and on 4.12.5-300.fc26.x86_64 it stops. -- 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/20171030/d3a3b717/attachment.html>