[PATCH] multiple instances of ipfw(4)
vadim_nuclight at mail.ru
Mon Jan 30 21:08:37 UTC 2012
Hi Ermal Lu?i!
On Mon, 30 Jan 2012 13:01:13 +0100; Ermal Lu?i wrote about '[PATCH] multiple instances of ipfw(4)':
> from needs on pfSense a patch for allowing multiple intances of
> ipfw(4) in kernel to co-exist was developed.
> It can be found here
Hmm, looking at the lines
if (oif && !(oif->if_flags & IFF_IPFW_FILTER))
it appears that a patch is made against somewhat private, I couldn't find that
in stock FreeBSD.
> It is used in conjuction with this tool
> It allows creation of contextes/instances and assignment of specific
> interfaces to specific contexts/instances.
It is not clear how to add a rule to a specific instance with this program.
> Surely i know that this is not the best way to implement generically
> but it gets the job done for us as it is, read below.
> What i would like to know is if there is interest to see such
> functionality in FreeBSD?
> I am asking first to see if there is some consensus about this as a
> feature, needed or not!
> If interest is shown i will transform the patch to allow:
> - ipfw(8) to manage the contextes create/destroy
> - ipfw(8) to manage interface membership. Closing the race of two
> parallell clients modifying different contextes.
> There is another design choice to be made about storing the membership
> of interfaces into contexts/instances, but i do not see that as
> It is quite handy feature, which can be exploited even to scale on SMP
> machines by extending it to bind a specific instance(with its
> interaces) to a specific CPU/core?!
Not so simple/straightforward questions. On the one hand, there are at least
/some/ people who need this. So the ipfw 'call'/'return' actions were already
implemented, first appearing in 9.0-R / 8.3-R. And melifaro@ has patches to
ipfw table allowing matching againt ifname, setting tablearg, which in
conjunction with 'call' or 'skipto' could be used to make essentially the same
functionality as your proposed patch, already in stock FreeBSD.
On the other hand, both ipfw contexts and ipfw 'call' are very half-measures.
The only goal was to give people something right now, and see how much this
will be demanded, what feedback they'll give, etc. It is obvious there is no
wide testing of 9.0-R (and 8.3-R too) right now.
What I mean here about half-measures? The ipfw 'call' is just a sketch of my
old ideas to completely reorganize ipfw to support multiple rulesets. To be
generic and Right Thing(tm), this is a HUGE work, because:
- each ipfw chain becomes independent netgraph(4) node
- generic ng_pfil node usable not only for firewalls
- chains may be called from each other (see iptables)
- chains (actually netgraph nodes) may be bind to ifaces or any other place
- main unnamed chain is called from pfil as before
- rewrite ipfw & dummynet management from setsockopt() to netgraph messages
- completely rewrite ipfw dynamic rules to not conflict with multiple
rulesets, as now they just jump to parent static rule (need to be more like
pf or iptables states). This item is hard but essential (you'll get a mess
jumping to another ruleset), and ipfw contexts don't handle ot
- while here, do other needed things, e.g. adding support for modules in both
kernel and userland, loadable opcodes, keywords, etc.
Even if not add something like bpf, that's ipfw_ng is probably a more major
change than both ipfw2 and ipfw3 :)
Due to various reasons in my private life, I was unable to do it in my spare
time previous years. My new employer is a provider using FreeBSD on most
machines, so I hope I could finally begin doing it at work (and for work),
but only several months later after more actual tasks.
But, all of this only makes sense to be generic for needs of broad masses of
our users. And in pfSense ipfw users are actually only it's authors (all
others see web interface), so it's better and more practical to not rely on
such complex solution, but rather on something more simple and specialized for
their needs. Such as your proposed ipfw contexts.
WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight at mail.ru
[Anti-Greenpeace][Sober FreeBSD zealot][http://nuclight.livejournal.com]
More information about the freebsd-net