laetus wrote:
> I was not sure if RH 6.1 included ip_masq_ftp
> automatically, so on Machine A (the firewall), I
> issued a "modprobe ip_masq_ftp.o" command and
> then used the /etc/rc.d/init.d/inet script that
> Redhat provides to restart the inetd daemon. I
Inetd doesn't have anything to do with masquerading ;)
You were correct to believe that the module had to be loaded manually.
If I understand the docs, they can't be built into the kernel, or
autoloaded.
However, the ip_masq_ftp module is for clients, I don't think you can
properly masquerade an FTP server.
> The problem. 1) If a client on the outside of my
> network is behind a firewall, even if I tell the
> FTP client to use PASV mode, I can connect to
> Machine B's FTP but not do an "ls" of any
> directory.
Under PASV mode, the ftp server opens a port and reports it to the
client. The client then connects to this port to exchange data. When
the server is behind a firewall, the client can't reach this port.
> 2) Even if a client on the outside of my network
> is NOT behind a firewall, and I tell it to use
> PASV, the same problem occurs. If I don't tell
> it to use PASV, then it works fine (it can
> connect to Machine B's FTP server).
When you aren't using PASV mode, the client opens a port, and the server
connects to that to exchange data. When the client is behind a
firewall, again, that doesn't work.
I'm not really sure if this can be (easily) made to work. If you were
to forward a range of ports into the ftp server, it may. I don't
however, know what ports those are... ngrep may help you out. You can
use it to examine the data stream and see what ports are being used.
It occurs to me that the experimental "virtual server" kernel extentions
may address this problem. The URL http://www.linuxvirtualserver.org/ is
mentioned in the docs. Check that out.
MSG
--
To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
as the Subject.
