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
> 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
> 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.