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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to