Hi Gregory, On Tue, Feb 06, 2018 at 03:40:20PM +0100, Gregory Vander Schueren wrote: > Hello, > > I have the following IPv4 network: > > FTPClient <-----------------> Proxy <--------------> FTPServer. > 10.0.0.2 10.0.0.1 1.1.1.1 1.1.1.2 > > FTPClient connects to FTPServer in PASSIVE mode, meaning the FTPClient > initiates the data connection towards FTPServer. Proxy performs NAT in the > POSTROUTING chain using the iptables MASQUERADE target. On Proxy, I use the > iptables TPROXY target to redirect the FTP data connection towards a local > socket. > > Upon accept() on this socket, the address returned by accept() is 1.1.1.1, > not the IP of the Client (10.0.0.2) as I expected. Using getpeername() also > returns 1.1.1.1. For other TCP connections than FTP accept() or > getpeername() returns 10.0.0.2. > > I noticed this only occurs when using the NF_CONNTRACK_FTP and NF_NAT_FTP > kernel modules. > > Note that I was able to retrieve the FTPClient IP on Proxy from > /proc/net/ip_conntrack. I also made a quick patch to add a SO_ORIGINAL_SRC socket option > (similar to SO_ORIGINAL_DST) which allows to retrieve the FTPClient > IP. Since this option does not exist yet, I am wondering if this is > relevant to add such an option? You can use libnetfilter_conntrack to do this these days, via ctnetlink. > Also, this does not occur in IPv6. > > Is this behavior normal? Probably it is related to your ruleset? You could post an example to reproduce the issue and your kernel version. Thanks. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
