[ previous ] [ next ] [ threads ]
 From:  Peter Curran <peter at closeconsultants dot com>
 To:  Chris Buechler <cbuechler at gmail dot com>, Vincent Fleuranceau <vincent at bikost dot com>
 Cc:  m0n0wall dash dev at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall-dev] any plans on switching to pf?
 Date:  Wed, 10 Nov 2004 09:46:18 +0000
My 2p worth....

I have (and continue to) used pf extensively since it first came out in 
OpenBSD 3.0.  I remain a committed OpenBSD user and my dalliance with 
m0n0wall is really a frustration at the lack of interest in the OpenBSD 
community in building GUI frontends for the system.  In my odd moments I am 
quietly plugging away at a port of m0n0 to OpenBSD.

I know Manuel has a dislike of userland features for firewalling and has in 
the past expressed a dislike for such things from a performance viewpoint.  
This is an understandable viewpoint, but I thik it is wrong to allow this one 
issue to cloud the general discussion of ditching ipf in favour of pf.

Based on like for like comparisons in OpenBSD 3.4, the performance of pf is 
somewhat better than ipf - largely because of the packet matching algorithms 
used in stateful operations.  Moreover, features such as dynamic rules using 
tables and anchors mean that in many cases pf is vastly faster and easier to 
use in an embedded environment than ipf.

Add to this CARP, ALTQ (with its support for a variety of traffic management 
and QoS scenarios) and the incredible pflog system that allows feeding of 
logged packets to an external analyser or IDS and I have no doubt which is 
the better firewall.

In fact, I may be so bold as to suggest that if m0n0 went down the pf route, 
it may as well kick FreeBSD into touch and just cut across to OpenBSD.

I have no experience at all of using pf on FreeBSD, so I do not know if the 
same level of integration and functionality achieved on OpenBSD is available 
under FreeBSD 5.3, but my experience of using it on OpenBSD leaves me in no 
doubt at all of which firewall is the best (and it isn't ipf).


On Wednesday 10 November 2004 09:51, Chris Buechler wrote:
> On Wed, 10 Nov 2004 10:38:37 +0100, Vincent Fleuranceau
> <vincent at bikost dot com> wrote:
> > -------- Original Message --------
> >
> >
> >
> > I've not used recent ftp-proxy version, but if it was just an horrible
> > thing, I guess the OpenBSD or PF developers would have enhanced it for a
> > long time now...
> >
> > Any feedback from the pfsense team?
> Part of an email I sent to Manuel:
> --
> Scott is running into other issues as well working on pfSense, like on
> FreeBSD you can't use a filtering bridge w/pf because of limitations
> in pfil.  In OpenBSD, everything is native hooks to pf, so it doesn't
> have that issue.  Scott says he knows how to fix that though, and I
> guess it isn't going to be extremely difficult.
> --
> Scott also thinks he'll be able to work around the other issues Manuel
> described, though it's far too early to tell.  NAT breaking certain
> protocols could definitely be an issue.
> I believe Manuel's comments on ftp-proxy were more from a performance
> and design perspective (going through userland rather than staying in
> kernel) than anything from a functionality standpoint.  The OpenBSD
> team tends to do things more securely over doing them faster, so that
> might be the reason for that design choice.  But I'm just speculating,
> when it comes to kernel stuff, or any deep programming for that
> matter, I'm very clue-deficient.  :)
> -Chris
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: m0n0wall dash dev dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash dev dash help at lists dot m0n0 dot ch

Peter Curran				  Leveraging Internet Technology
Close Consultants			       for Businesses
p: +44-1225-463700			 
f: +44-1225-463705			  
e: peter at closeconsultants dot com		  
sip: peter at closeconsultants dot com 

This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.