[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reverse ftp-proxy patch and active FTP

Daniel Hartmeier wrote:

Passive/active can be ambiguous, for the client passive mode means the
clients connects to the server for data connections. But from your
further description I think you mean data connections from the server to
the client, right?

Yes, that is correct.

As I understand your setup, you have a dedicated external address which
you binat to the ftp server's local address, as in

binat on $ext_if from to any ->

where would be the ftp server's internal address, and the dedicated external address of the firewall.

You run ftp-proxy in reverse mode from inetd.conf, like stream tcp nowait root /usr/libexec/ftp-proxy \
   ftp-proxy -R

and redirect incoming ftp control connections from external clients to
the proxy using

 rdr on $ext_if from any to port 21 \
   -> port 8021

While ftp-proxy in reverse mode doesn't usually need a redirection, in
the binat case I think you need one to prevent the incoming control
connection from simply getting forwarded to the internal address,
bypassing the proxy.

Try following a control connection with tcpdump, it should come in on
$ext_if to, get redirected to port 8021, where inetd
starts an ftp-proxy process. The proxy connects to, and the
proxied control connection should work both ways (login should work).

I will try this later. For now, I don't have any nat rules on the IP address that I am trying to use as an external address for the FTP server - I am just trying to get the proxy to work by having it listen on one of the firewalls addresses and bouncing inside (where the server's IP address that the FTP server is running on as well doesn't have any NAT rules).

When the client requests a data connection from the server to the
client, follow that with tcpdump. You should see the data connection
come in on $int_if of the firewall, then leave $ext_if.

One possible problem is that ftp-proxy doesn't bind to the right
external address (in the presence of multiple aliases), and the external
client refuses or ignores a data connection from an unexpected source.
This should be visible in a tcpdump on the external interface.

This is exactly the problem just confirmed with tcpdump. The firewall/proxy is trying to establish the data connection back to the client from its primary IP address, rather than the address that I configured xinetd to listen to. I'm no network programming guru, so I don't even know if its possible to see what address [x]inetd was listening on, but I quickly coded up a new argument to specify which IP address data connections come from, and so far it seems to work.

I was going down this path last night, and did verify that I could establish connections from any IP on the server just in case, but both FTP clients I was using to test are behind NAT's, so of course if we don't establish the data connection from the same IP it is never going to get past the NAT on the client side .. duh.


Thanks a lot, I really appreciate it.

I am still testing the ramifications of my patch, and like I said, I'm not really a network programming guru, but if anyone wants it, they are free to have it.