Re: Reverse ftp-proxy patch and active FTP

[Tim Pushor]

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 10.1.2.3 to any -> 62.65.145.30

where 10.1.2.3 would be the ftp server's internal address, and
62.65.145.30 the dedicated external address of the firewall.
You run ftp-proxy in reverse mode from inetd.conf, like

 62.65.145.30:8021 stream tcp nowait root /usr/libexec/ftp-proxy \
   ftp-proxy -R 10.1.2.3:21
and redirect incoming ftp control connections from external clients to
the proxy using
 rdr on $ext_if from any to 62.65.145.30 port 21 \
   -> 62.65.145.30 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 62.65.145.30:21, get redirected to port 8021, where inetd
starts an ftp-proxy process. The proxy connects to 10.1.2.3:21, 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.

Daniel
 

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.

Tim