Date: Sun, 20 Feb 2011 23:06:15 +0000 (UTC) From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> To: Maxim Khitrov <max@mxcrypt.com> Cc: freebsd-pf@freebsd.org Subject: Re: (no) PF from OpenBSD 4.7: Message-ID: <20110220225113.E13400@maildrop.int.zabbadoz.net> In-Reply-To: <AANLkTimeob2Oa6CRzuB8ssTF5mDXXndn00jUcpRtDHK4@mail.gmail.com> References: <AANLkTi=P_KikS_GHn1h265ScL%2BcbwN1q4VitaMcWVuWx@mail.gmail.com> <alpine.BSF.2.00.1102192242110.4222@qvfongpu.qngnvk.ybpny> <AANLkTinqockMyjNjxesATm1yFNdRNBVcUaG=Z2a0PQw5@mail.gmail.com> <alpine.BSF.2.00.1102201611490.13814@qvfongpu.qngnvk.ybpny> <AANLkTimeob2Oa6CRzuB8ssTF5mDXXndn00jUcpRtDHK4@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 20 Feb 2011, Maxim Khitrov wrote:
Hey,
> On Sun, Feb 20, 2011 at 4:16 PM, jhell <jhell@dataix.net> wrote:
>>
>> On Sun, 20 Feb 2011 13:27, eirnym@ wrote:
>>>
>>> On 20 February 2011 06:50, jhell <jhell@dataix.net> wrote:
>>>>
>>>> On Fri, 18 Feb 2011 03:26, eirnym@ wrote:
>>>>>
>>>>> I heard while ago about packet filter update coming, but there're no
>>>>> news about. Which status of this update?
>>>>>
>>>>
>>>> This was for OpenBSD pf45 not pf47. The patchset should be somewhere in
>>>> the
>>>> archives for HEAD.
>>>>
>>>
>>> Differences between pf45 and pf47 are more smaller than between pf45
>>> and current pf.
>>>
>>> I've found them, but there no status about. Should I ask same question
>>> in freebsd-current@ mail list?
>>>
>>
>> Difference being that after pf45 there was a syntax change that is nearly
>> incompatible with the current pf41-45 syntax so AFAIR based on that pf45 was
>> voted as the most likely to be merged into HEAD.
>>
>> There is an email from Theo @openbsd.org about the syntactic changes that
>> have made people a little jumpy at adopting pf > 45 but eventually it will
>> work its way in.
>>
>> What advantages to using pf47 over using pf45 have you found in ``real use''
>> ? and how realistic are those changes for the masses ?
>
> The firewall (FreeBSD 7.3) that I manage at work currently contains 36
> nat/rdr rules and 39 filter rules. It's responsible for passing
> traffic between 4 different networks. After reading the OpenBSD pf
> FAQ, the biggest advantage that I see of pf47+ is the ability to
> combine related filter/nat/rdr rules, making the entire ruleset easier
> to maintain.
>
> Personally, I would love to see the latest version of pf make it into
> FreeBSD 9 or even one of the 8.x releases. Compatibility with existing
> syntax is not as important to me as the ability to simplify my set of
> rules.
I can already tell you that this will most likely not happen. There is a
lot of discussion (mostly private) going on and we'll see what the plan
to move forward will be after 9.0.
For 9.0 it will be pf45 + cherry picking + patches.
The current ongoing work, based on Ermal's previous patches is in
svn://svn.freebsd.org/base/projects/pf/pf45/ as of a couple of days and
Ermal and I have been working on cleaning it up and finalizing it the last
days. You can check that out (it's a HEAD from 2 days ago) which passes
universe now. It needs more whitespace cleanup and a tiny bit here
and there but is very good for testing!
If you simply care about simplifying your ruleset, use a preprocossor
but frankly with 36+39 entries I wouldn't even start pondering about
simplification as that still fits on a single screen.
Seriously, for most users modifying the ruleset when updating IS the
worst that can happen, the same way two different versions of pfsync
don't work together anymore, etc. The lessons learnt from breaking
backward compantibility last time are still very present and though we
cannot currently get it 100% right we try hard to do the best we can
to not break again. Similar reasoning applies to 3rd party mgmt
software that sits on top of the syntax in a UI, etc.
/bz
--
Bjoern A. Zeeb You have to have visions!
Stop bit received. Insert coin for new address family.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110220225113.E13400>