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 <[EMAIL PROTECTED]> 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,                      | [EMAIL PROTECTED]
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | [EMAIL PROTECTED]
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News


_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to