On Thu, 17 Feb 2005, Justin Sirois wrote:

> Thanks for the link.
> 
> It looks like that requires a dedicated external IP, and that the FTP is 
> passive.

You must be referring to some off-list reply, probably with a reference to
1:1 NAT.  That's not a requirement, although it does make certain things
work out more easily for FTP.

Actually, on the server side, active is the easier case.  Though a server
that doesn't support passive is not RFC-compliant.

> Also, my FTP server isn't assigned a static IP address.
> Is there an easy way to route ports 20 and 21 to the ftp server based on MAC 
> address, or the hostname?

Yes - inbound NAT.  And it's not just a "routing" issue, since addresses
are being altered in the process.  NAT is not "automagic" for incoming
connections, so anyone attempting to set up servers behind a NAT router
should understand the concepts of NAT first.

> Justin Sirois said:
[...]
> >
> > Before trying FTP the only additional rule I had was
> > *    OPT1    *    *
> >
> > My FTP server is on OPT1 and is active FTP
> > I tried the rule
> > TCP/UDP    *    21    [server]    21

When specifying "rules", be clear as to which type of rules are being
mentioned, rather than expecting it to be implied by the format.  In this
case, it appears you're talking about firewall rules, in which case
specifying 21 as a "source port" is inappropriate.  It's almost never
appropriate to specify a non-wildcard source port in a firewall rule.

BTW, FTP never runs on UDP, so "TCP/UDP" isn't really the appropriate
protocol choice.

On Fri, 18 Feb 2005, Chris Bagnall wrote:

> Here's my firewall setup:
> 
> Proto | Source | Port | Dest | Port
> 
> TCP  *  *  Cronus  21 (FTP)   
> TCP  *  *  Cronus  23580 - 23590
> 
> Cronus is an alias pointing to the internal IP of the FTP box. You'll also
> need the equivalent port forwarding rules.

Though it's more straightforward to configure the NAT rules and use the
"auto-add firewall rule" option.  Also note that active mode should work
without the second part.

> There is absolutely no need to forward port 20 - it's used for outgoing data
> in active mode only. It's outgoing, not incoming, so the default firewall
> allow rule should catch it.

Well, the *real* reason you don't forward port 20 is that it's only used
as the *source* port of active-mode data connections.  Hence it's never of
any concern for either NAT or firewall purposes, in spite of the many
people who keep posting that you have to worry about it.

> What you do need in passive mode, though, is a range of ports to allow the
> server to connect "back" to the client. Choose a few ports (you'll not need

Umm, no, that would be the active-mode case.  This is a range of ports
that the server can *listen* on for *incoming* connections from the
client.

> many - allow the maximum number of concurrent connections you expect to get)
> at random and port forward those. Obviously you'll need to tell your FTP

You may need *many* more ports than the allowable number of concurrent
connections.  Each *transfer* uses a data connection which is closed at
EOF, and the port doesn't become reusable until after the TIME_WAIT period
has expired.  Thus, the server may choke on port unavailability.

The narrower the port range, the easier it is for an attacker to guess the
port number and hijack the connection.  OTOH, it can't be *too* wide if
you have to provide a number of such ranges.

> server to use this range as its PASV port range (most FTPs will default to
> using any port from 1024-65535 unless you tie them down to specific ports).

Actually, the default behavior is usually to let the OS assign the
port.  This would not usually be from the entire 1024-65535 range, but
rather from either the "old-style" 1024-5000 range or the
"new-style" 49152-65535 range.

One problem with this kind of explicit port assignment is that any
"smarts" that the OS may have to assign ports less predictably (for
security reasons) is unlikely to be implemented in the FTP server itself,
so assigning an explicit port range almost always reduces security.

In any case, it's *not* necessary to set up an explicit port range for
this.  IPFilter's NAT code has an "FTP hack" which works for both the
active-mode client and passive-mode server cases (I just verified that
this works).  The only thing necessary is to open the ephemeral port range
through the firewall.  But possible gotchas are:

1) If the ephemeral range used for the data connections differs from the
range configured in the firewall, then those connections will be blocked.  
But I believe IPFilter's NAT uses "aggressive" port remapping which will
always put the ports in *its* idea of the ephemeral range, rather than
only remapping ports with "collisions".  Not sure if it gets the range
from the sysctls, but empirically it looks like it uses the 49152-65535
range.

2) Since there doesn't seem to be a configuration option for the "FTP
hack", it probably only works for the standard port 21 (*after* any NAT
remapping).  FTP on a nonstandard port would be more problematic.  I think
IPFilter has this flexibility (via the "map ... proxy ..." rules), but
it's not accessible through m0n0wall.

3) NAT "FTP hacks" are always fragile due to the problems associated with
manipulating the data connection stream at the packet level.  For example,
Cisco has fixed bugs in that area as recently as a few months ago.  
Unfortunately, I don't think m0n0wall has an option to disable the FTP
hack in the case where it's made unnecessary by the explicit redirection,
except by using a nonstandard port.

					Fred Wright