[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reverse ftp-proxy patch and active FTP
Daniel Hartmeier wrote:
Yes, that is correct.
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?
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).
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 -> 22.214.171.124
where 10.1.2.3 would be the ftp server's internal address, and
126.96.36.199 the dedicated external address of the firewall.
You run ftp-proxy in reverse mode from inetd.conf, like
188.8.131.52: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 184.108.40.206 port 21 \
-> 220.127.116.11 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 18.104.22.168: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).
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.
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.
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.