Very Computer

For the past 2 days I've been trying to get ftp forwarding to work in
our company's network.

The configuration is such:

Firewall - runs ipmasquerading & ipmasqadm portfw.
Internal Machine with FTP server.

The firewall linux box binds to several Internet IP addresses (IP
Aliasing) and when a client FTP to one of those IPs, the ftp traffic
will be port forwarded to the internal machine's FTP server.

This configuration works well only when a Linux FTP client makes an
active connection to the ftp site. It will not work for passive mode
cos' the author for ipmasqadm told me that it is not supported yet.

Anyhow, the question is:

Why the hack Windows FTP client wouldn't be able to connect to the same
FTP server that's working for Linux FTP client?

I've tried CuteFTP, WSFTP, LeechFTP, FTPControl to no avail. These
client's allow you to setup passive connection but I'm not sure if
their default is active connection or not??? I'm saying this because
when I did a "netstat -M" on the firewall during the ftp session from
the Windows Client, there's not connection from the source ftp-data
port (20) to a high port on the firewall, which is what active
connection does.

Any tips/ideas/suggestions on how I can achieve FTP forwarding is very
much appreciated! Thanks.

Winston

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Alternatively sod port forwarding and use a proper ftp proxy - look at
the one from the firewall toolkit (TIS) or Juniper.

        Nigel.

--

[ Playing with technology razor blades - close to the bleeding edge  ]

Quote:> Why do this - its a silly design in that you are letting traffic onto
> your internal network that does not need to be.  Its much easier to
> just clone the ftp config onto your firewall box and run the ftp
> server there - which you can chroot and*down and make sure is
> fairly secure.  The simpler you keep things, the easier it is to
> secure.  Make things baroque and there are more nooks and crannies for
> a cracker to lever on.

Quote:> Alternatively sod port forwarding and use a proper ftp proxy - look at
> the one from the firewall toolkit (TIS) or Juniper.

|>The firewall linux box binds to several Internet IP addresses (IP
|>Aliasing) and when a client FTP to one of those IPs, the ftp traffic
|>will be port forwarded to the internal machine's FTP server.

|Why do this - its a silly design in that you are letting traffic onto
|your internal network that does not need to be.  Its much easier to
|just clone the ftp config onto your firewall box and run the ftp
|server there - which you can chroot and*down and make sure is
|fairly secure.  The simpler you keep things, the easier it is to
|secure.  Make things baroque and there are more nooks and crannies for
|a cracker to lever on.

   So you are advocating running lots of potentially insecure services on
your firewall?  Where are you posting from again? :-)  To be secure, the
only thing running on a firewall should be IPchains and syslog.  Anything
else is a potential crack in your first line of defense.  You last line is
correct... Keep the firewall simple.
   Now, if you port forward FTP to your box inside, a cracker has only one
port to attack that box from.  You can set up the box to log and alert when
a user is running an interactive session on port 80 of your web server, for
example, and have the firewall black hole him automagically.

|Alternatively sod port forwarding and use a proper ftp proxy - look at
|the one from the firewall toolkit (TIS) or Juniper.

   Also works, but could bring in it's own security holes.  Port forwarding
is a very secure way to do things.  It is also harder to crack.  After all,
if you do crack the firewall, you now have to spoof NAT.

            Lee

--
SCSI is *NOT* magic. There are *fundamental technical reasons* why it is
necessary to sacrifice a young goat to your SCSI chain now and then. * Black
holes are where God divided by zero. - I am speaking as an individual, not
as a representative of any company, organization or other entity.  I am
solely responsible for my words.

Quote:

> ipportfw (for 2.0.x kernels) and ipmasqadm (for 2.2.x kernels) solve
the
> problem. I use ipmasqadm on my 2.2.10 kernel with ip_masq_ftp loaded,
> everything's fine.
> Just have a look at IP masquerading homepage and last version of
> IP-masquerading HOWTO.

were you able to ftp (using Windows FTP Client) from an external
machine to a machine behind the firewall using port forwarding?

I'm have kernel 2.2.6 & ip_masq_ftp loaded. FTPing from external to
internal works only if I use a linux ftp client (active connection) but
not a Windows client.

I think that the windows client takes the source address found in the
ftp packet's body and place it in its return packet's header. However,
that source address in the body was not translated by the firewall from
the internal IP to its own IP.

Winston

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Quote:> Just to confirm:

> were you able to ftp (using Windows FTP Client) from an external
> machine to a machine behind the firewall using port forwarding?

> I'm have kernel 2.2.6 & ip_masq_ftp loaded. FTPing from external to
> internal works only if I use a linux ftp client (active connection)
but
> not a Windows client.

> I think that the windows client takes the source address found in the
> ftp packet's body and place it in its return packet's header. However,
> that source address in the body was not translated by the firewall
from
> the internal IP to its own IP.