Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 21 Feb 2000 01:52:30 -0700 (MST)
From:      Ivan Fetch <ivanfetch@technologist.com>
To:        freebsd-questions@freebsd.org
Cc:        "James A. Mutter" <jmutter@ds.net>
Subject:   ipf (packet filter) vs. ipfw
Message-ID:  <Pine.LNX.4.20.0002210144100.238-100000@ibis.ivanfetch.tzo.com>
In-Reply-To: <38B055AB.30F80438@ds.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Hello,
   The recent mentioning of the ipf howto on this list has reminded me to
ask this:

Managing firewall rules with ipf instead of ipfw seems to have some
advantages, notably the "keep state" functionality - ipf keeps more track
of established connections on it's own, where as ipfw only seems to be
able to tell "is it a syn packet or not".  I was wondering what the fire
wall enthusiasts on this list thought about ipf vs. ipfw.  Some other
questions I have (which hopefully some here can assist with) are:

1. Does anyone know which version of ipf ships with FreeBSD
3.4-release?  There seems to be no way to tell which version you have
(i.e. -v or -V switch).  Some of the functionality mentioned in the how-to
seems to be missing - specifically the ability to specify that ipf should
automatically log to syslog with a specific level (log level auth.info
...), as well as specifying rules like (map 192.168.1.0/24 ->
whatever...) for NAT.

2. If I keep some ipfw based rules, and use ipf rules as well, the ipfw
rules seem to take affect first, then the packet is passed onto ipf based
rules.  IS this statement at all accurate.  As I could not get NAT to work
with ipf, I kept the rule which diverted trafic to the natd daemon
(created by ipfw), and created all other fire wall rules with ipf.  This
seems to work fine <???>.

Thank you for any points-of-view,
Ivan.




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.20.0002210144100.238-100000>