I think part of the bigger issue are applications other than FTP. I personally would love to host servers for games that dynamically assign outgoing ports to clients after the client authenticates via a static port (example: Tribes 2 uses port 25000 for initial authentication, but after that the server assigns that player a different transfer port for the actual game communication.).
As it is I can force Tribes 2 to use a range of ports for players and I have poked holes for that range...this is by far not the best security method though and not all applications allow for forcing a static range of ports. --David Chubb > -----Original Message----- > From: Julien Bordet [mailto:[EMAIL PROTECTED] > Sent: Monday, March 01, 2004 2:05 PM > To: Ed White > Cc: [EMAIL PROTECTED] > Subject: Re: Brige, Traffic Shaping and FTP > > > Hi, > > I'm not sure whether Ed's idea would be the best way to do > it, but it raises a very good question that makes pf > sometimes not useful as it should be. > > When one setups a firewall, I agree that it can be globally > the same whether FTP is transparent proxified through user > space proxy or directly managed by the kernel. Both cases can > be efficient, and the former is simpler and probably clearer, > as it reduces the amount of protocole specific code into the kernel. > > However, when one does bridge traffic shaping, this is not > the same thing at all : proxifying means that your are not > bridging any more, using a IP address for the bridge, and so > on. I really think it is a very dirty solution. The kernel > space solution here is much cleaner, as it is transparent for > the firewall administrator. Thus he does not have to take > care of the ports used by the FTP protocol. > > The idea of ftpsesame could be good, but it does not seem to > be on the way to inclusion into the tree... > > I really think the OpenBSD bridge/traffic shaper solution is > the best available (by far). But having to proxify FTP or > managing FTP data by ports is such a pain in the neck ... > > Julien >
