I think I have the situation described in that link as, "Deadlock - When
there are Restrictive Firewalls on Both Sides."

If I try FTP'ing from a Linux client to a FTP server behind the monowall,
the Linux client defaults to using Passive FTP and I see blocked packets
logged by Monowall. (Client, high numbered port blocked trying to connect to
ftp server port 20.)

If I tell my FTP client to use active FTP instead, I see no blocked packets
from Monowall, however, the firewall closest to my Linux client is blocking
the packets this time.

From the Monowall manual, 1:1 appears it might work. Have enough public
ipaddresses that 1:1 NAT should be okay. The only thing I am unclear about
now is whether this will solve the FTP issues, and whether I need to
reconfigure all the hosts behind the monowall.

Can I give an address like 10.0.0.1 to the Monowall WAN, 1:1 NAT 10.0.0.1/27
to our public /27 address space, and then get the upstream router admin to
change the route to our network to go through 10.0.0.1 instead of the
gateway it is using now?

The reason I'd prefer that is I want the Monowall to be as much of a
"drop-in" component as possible, minimizing the amount of reconfiguration
needed for the hosts that will be behind it. That's why I originally went
for bridging, but that isn't working out for FTP.

On 5/17/06, Chris Buechler <cbuechler at gmail dot com> wrote:
>
> On 5/17/06, Brian McEntire <brian dot mcentire at gmail dot com> wrote:
> >
> > Previous replies to the list said FTP won't work without NAT.
> >
>
> The FTP fixup in ipfilter won't work without NAT, but you don't need
> to have that to have workable FTP.  I use FTP clients and servers in a
> bridged setup, and it isn't a problem.
>
> I suggest: http://www.ncftp.com/ncftpd/doc/misc/ftp_and_firewalls.html
>
> -Chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
>
>