On 18.01.2004, at 00:34, Brian Z wrote:

> Such things as H.323, FTP, IRC's DCC, and a plethora of other protocols
> simply don't work when connections are initiated from behind a NAT
> implementation. In the netfilter world, these connections are tracked
> and fixed (mangled might be a better term) by additional netfilter
> (well, kernel) modules. How do ipfilter, ipfw, and <BSD packet filter 
> of
> choice> deal with these issues? Do they simply not work at all? I pose

There are some proxy modules for ipfilter, and m0n0wall uses the FTP 
proxy by default, which means that outbound active FTP connections 
(i.e. FTP client behind m0n0wall) are no problem. It's a different 
story if you want to run a passive FTP server behind m0n0wall, as that 
proxy only works for outbound connections. Looking at the ipfilter 
source code, I see that there are proxy modules for H.323, IPsec, 
NetBIOS, Real Audio and RCMD too. They're not well documented and I 
have no idea if they actually work, though. Has anybody tried them 
successfully?

> this question after attempting DCC connections after implementing

ipfilter 3.4 doesn't have an IRC proxy, but ipfilter 4.0 does (which is 
still in beta though).

> m0n0wall, and having them fail. Is this the reason passive FTP is used
> when upgrading (my only experience with FTP upgrading has been through
> the WAN interface, with necessary port maps set)?

No. Actually, with the changes to the filter rule generator in pb25, 
active mode FTP works as well for firmware uploading, so that notice 
will be removed in the next release.

- Manuel