Date: Mon, 18 Dec 2006 00:03:05 +0100 From: "=?ISO-8859-1?Q?Ermal_Lu=E7i?=" <ermal.luci@gmail.com> To: freebsd-net@freebsd.org Cc: freebsd-pf@freebsd.org Subject: PF - netgraph integration Message-ID: <9a542da30612171503r2b032072j2acd1f48537081e1@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Hello, i am writing a netgraph module to make PF communicate with netgraph subsystem and was wondering which method is better of handling PF tags on netgraph part, since they use strings for matching. Is it better patch ng_tag to handle strings too, like setting the type of hook to either PF tags compatible or normal(tag_id/current) one? Or just make an kinda aliasing of tag_id in ng_pf(the module i am writing) so when tags come from PF -> netgraph we assign a tag_id(consistent through netgraph) to the specified PF_tag, user configurable, and then revert to PF_tag when communicating from netgraph -> PF? Another issue is the way to handle rule parsing in PF when packets return from netgraph. Since PF cannot guarantee rule position/number to be the same after a reload of its ruleset. One i have thought about is use reinjecting the packet on the rules with one of M_PROTO[1-5] flags so we can distinguish if the packet have been sent once to netgraph(although i don't know if this is safe since other protocols/applications might use this flags)! Maybe intodruce a M_NETGRAPH_TO_PF flag like M_SKIP_FIREWALL, but i know this is not a preferable one since it inserts a special case to the kernel?! One forced solution is to create a 'static' anchor where rules about such packets can be created?! The last choice, maybe, is to pass the according rule to netgraph and refind it when sending the pakcket back to PF so it continues to the next rule, after the one we saved, but this seems really not efficent?! Please can you help out with these issues i am trying to find a good solution but ideas would be welcomed :). Thanks.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9a542da30612171503r2b032072j2acd1f48537081e1>