[PATCH] multiple instances of ipfw(4)

[Ermal Luçi]

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
>> https://raw.github.com/bsdperimeter/pfsense-tools/master/patches/RELENG_9_0/CP_multi_instance_ipfw.diff
>
> 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
>> https://raw.github.com/bsdperimeter/pfsense-tools/master/pfPorts/ipfw_context/files/ipfw_context.c
>> 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
>> blocking.
>
>> 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
> - 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
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"



-- 
Ermal