[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reverse ftp-proxy patch and active FTP
On Sun, Mar 14, 2004 at 10:49:48PM -0700, Tim Pushor wrote:
> The problem is that I have a FTP server on inside that I am trying to
> get ftp-proxy (with the reverse patch on benzedrine) to proxy into, but
> I'm having trouble with active ftp. Passive works fine.
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?
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 -> 184.108.40.206
where 10.1.2.3 would be the ftp server's internal address, and
220.127.116.11 the dedicated external address of the firewall.
You run ftp-proxy in reverse mode from inetd.conf, like
18.104.22.168: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 22.214.171.124 port 21 \
-> 126.96.36.199 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 188.8.131.52: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).
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.