m0n0, or more precisely, ipf can track ftp sessions and will do what
necessary to make
active mode ftp session working properly. u can verify it by looking
at the ipnat -lv
output in the http://your.m0n0.ip.addr/status.php. u could find sth like

MAP 10.0.0.68       1234  <- -> 218.x.y.43     1234  [218.a.b.68 21]
        proxy ftp/6 use 1 flags 0
                proto 6 flags 0 bytes 1344 pkts 23 data YES size 392
        FTP Proxy:
                passok: 0
        Client:
                seq 3b7cb9703b7cb970 len 0 junk 0 cmds 1
                buf [LIST UpdateFiles.ini\015\012\012\000]
        Server:
                seq 4d22a1204d22a11f len 1 junk 1 cmds 227
                buf [44444ransfer complete.\015\012ata connection for
/bin/ls.\015\012ss as password.\015\012\000]

so i'm wondering did active ftp mode ever work before?.  if not, i
suspect it's a ftp svr
config problem. it might be ur ftp svr admin has disabled active ftp
mode, 'cause it's
considered insecure and many ftp svrs, like serv-u, don't allow it by
default unless they
see the incoming sessions are in the reserved ip ranges, say 10.0.0.0/24, 
172.16.0.0/12, 192.168.0.0/16, etc. if this is the case, an error msg
like "Only client IP
address allowed for PORT command" will be returned to ur ftp client.
and u can verify
it by looking at the log file of ur ftp client.

sorry for my poor english

On 6/9/05, Markus Fischer <markus at fischer dot name> wrote:
> Hi,
> 
> I'm expiriencing a wierd situation with m0n0wall and active FTP
> connection to one of our partner hosts.
> 
> I'm opening the ftp connections are for some time (browsing to the
> rather big directory structure remotely) works. But often at one point,
> wenn the internal PORT command is issued the ftp client seems to hang
> and later stops because of a timeout.
> 
> Whenever this timeout happens, I find multiple entries in the firewall log:
> 
> block | WAN | remote-ip 21 | my-public-gatewat-ip 4000 | TCP
> 
> The port of the remote-ip is always 21, the port on the public ip of the
> gateway varies but is usually in the range 2000 to 4000 or so.
> 
> I have not set up any rule to block these. I even added a rule for
> testing to accept all packets from everything to everything, and still I
> got those reported as blocked in the firewall log.
> 
> I've tested multiple ftp clients, all exhibit the same problem. The
> administrator of the remote company said he did many hours of debugging
> at its best and could only come to the conclustion that he suspects a
> problem in the ftp-nat module of my firewall (m0n0wall). He says his
> firewall does state matching he can see that many tcp connections are
> not correctly initiated from our firewall; packets are dropped.
> 
> I'm using version 1.11, generic-pc.
> 
> thanks for any pointers,
> 
> - Markus
> 
> ---------------------------------------------------------------------
> 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
> 
>