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 18.104.22.168 22.214.171.124 > > 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 126.96.36.199, > not the IP of the Client (10.0.0.2) as I expected. Using getpeername() also > returns 188.8.131.52. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html