netgraph related question

[Ermal Luçi]

I am glad that you are interested on this new features.

Well i don't know PF code as much as you but i think the hook point
can be better expressed with the semantics of
route-to/reply-to/dup-to.
It just fits better, my opinion always, the PF idea to use a rule with
netgraph-to in the beggining as it better expresses what it really
does.
One might argue it kinda mixes with anchor semantics but to my opinion
this is better, so a rule chooses what to pass to the hook and
netgraph(4) injectes it back.

The same can be applied to divert(4) with a divert-to keywork.
BTW, what is the need of divert(4) on PF if not for being used on
kernel proxy code or interaction with natd?! (i am not saying that PF
would not need such a feature)

P.S. sorry for the broken english is not my native language.


On 9/25/06, Max Laier <max at love2party.net> wrote:
> On Monday 25 September 2006 16:49, Ermal Luçi wrote:
> > I am curios how difficult would it be to write an netgraph module for
> > pf kinda ng_ipfw.
>
> Between 100 and 600 lines of code, depending how far you want to take it -
> see below.
>
> > And maybe looking for a pointer to which function this hooking needs to
> > be added.
> > After studing a little bit ng_ipfw and ipfw functions ipfw_check() is
> > the function which does the magic by a simple global variable, at least
> > as far a i can tell.
> > Now can it be done using the same ideas in PF too!
>
> The basic communication between netgraph and ipfw happens via mbuf tags
> attached to the packet.  Read the ng_ipfw(4) manpage for details on this.
> It is non-trivial to do something along those lines in pf as ruleset
> evaluation works completely different from what ipfw does.  i.e. the main
> problem one has to solve is: How do you express the netgraph hook in
> pf.conf?
>
> One possible sollution would be to have it as part of the scrub ruleset.
> This is quick and easy as the scrub ruleset is always evaluated, but it
> would be adverse to the general pf idea of stateful-filtering.
>
> The more involved sollution is to have the ng-hook as a rule option.  This
> gives all the benefits of stateful filtering, but requires a lot more
> changes in pf to make things work together.  The basic implementation is
> quite easy, however.  All you need to do is add the option to the
> pf_rule/pf_state structs and attach a mbuf tag accordingly.  The packet
> is then diverted to netgraph where ng_tag (or any other netgraph node)
> can have a look at it and eventually sent back.  In pf_test it will match
> the same rule/state again (you'd have to change a couple of things to
> avoid state irritations) and you can finally pass it, as it has a
> netgraph tag already attached.
>
> Support of divert(4) sockets is something along the same line.  It would
> be nice to have a way to send packets from pf to a divert socket, but the
> same problem applies: How do you express the hook-point in pf?
>
> I'd like to work on both of these problems, provided there is enough
> interest and we can come up with a proper sollution for the hook-point
> problem.
>
> Any ideas?
>
> > Ah, the reason i am asking this is just to integrate PF with ng_tag
> > which can do L7 filtering.
>
> --
> /"\  Best regards,                      | mlaier at freebsd.org
> \ /  Max Laier                          | ICQ #67774661
>  X   http://pf4freebsd.love2party.net/  | mlaier at EFnet
> / \  ASCII Ribbon Campaign              | Against HTML Mail and News
>
>