I hope this is not a well known issue that I happen to be ignorant
about:

I have a NAT box between our FTP server and the Internet universe.  In
the process of responding to active PORT requests (I hope I'm using
the right terminology here) the FTP server is expected to originate
the DATA connection from port 20, but address translation (MAP in
Darren's terminology) causes the port to migrate to the pool reserved
for outgoing connections.

On an OpenBSD server I have access to, this does not create a problem,
but a Solaris (I think) FTP client seems to reject the connection
(actually, it times out - more likely the firewall on their side is blocking
the incoming connection).

I have just re-implemented an existing firewall with brand new
thinking and more recent NetBSD code and I wonder (a) what mechanism
may be available to compel the connection to originate from the given
address but retaining port 20, and (b) how did I get it right on the
previous incarnation of the firewall?

Just to clarify: the rules involved are (it's a public server, so I
don't need to fake the addresses):

rdr de0 196.30.44.140/32 port 21 -> 172.24.16.240 port 20 tcp

and

map de0 172.24.16.0/24 -> 196.30.44.140 portmap tcp/udp 5001:6999

I'm not comfortable with the double specification, but I can't suggest
an improvement that would avoid possible inconsistencies.  What I'm
hoping for is a "map" rule that would ensure that port 20 is retained
without invalidating all the other mapping operations.

Or should I be looking at a completely different approach?  And if so,
what would it be?

++L