[PATCH] multiple instances of ipfw(4)
julian at freebsd.org
Tue Jan 31 09:20:11 UTC 2012
On 1/31/12 12:53 AM, Ermal Luçi wrote:
> On Mon, Jan 30, 2012 at 10:08 PM, Vadim Goncharov
> <vadim_nuclight at mail.ru> wrote:
>> 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))
>> return (IP_FW_PASS);
>> it appears that a patch is made against somewhat private, I couldn't find that
>> in stock FreeBSD.
> Yeah its not so polished patch, and the remaining parts are still
> there in the same repo.
> Though its redundant to this patch.
>>> 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.
> Simple example:
> - Create a context with members
> ipfw_context -a testctx
> ipfw_context -a testctx -n myiface0
> ipfw_context -a testctx -n myiface1
> - Set the context
> ipfw_context -s testctx
> - Continue business as usual with ipfw/dummynet
> ipfw add ....
> ipfw pipe create ....
> ipfw table add ....
>>> 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.
> Well it tends to get messy if you do not have a smart consumer
> handling the jumps.
> Its almost as reprogramming in ipfw language and somehow an admin
> needs to read this!
> The intention was be practical and allow easy troubleshooting.
>> 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.
> It depends on the needs, surely and how colorful you want it to be.
>> 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
what about the existing netgraph ipfw node someone wrote a few years ago?
I saw it but don't know if it was sent out publicly.
>> - 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.
> if you write a ip/tcp/udp/... stack on netgraph than i will write this :)
> Though its a matter of preference and how much work its needed to
> accomplish this!
> Surely ipfw has seen a lot of hacks in the past and will see in the
> future but i thik usability is more of a target
> rather than fancy design.
> But surely nothing should stop both ways.
>> 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.
> Surely enough you can take shortcuts in a customization but its not
> the point here.
>> WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight at mail.ru
>> [Anti-Greenpeace][Sober FreeBSD zealot][http://nuclight.livejournal.com]
>> freebsd-net at freebsd.org mailing list
>> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
More information about the freebsd-hackers