Date: Tue, 31 Jan 2012 09:53:30 +0100 From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= <eri@freebsd.org> To: vadim_nuclight@mail.ru Cc: freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [PATCH] multiple instances of ipfw(4) Message-ID: <CAPBZQG0gsi--ACj8exyAHTjT7yso0Kxh-A9YwdsKkabgJQXesA@mail.gmail.com> In-Reply-To: <slrnjie1m9.2tp2.vadim_nuclight@kernblitz.nuclight.ipfw.ru> References: <CAPBZQG32iyzkec4PG%2Bqay9bKfd0GiffKyRBapLkATKvHr7cVww@mail.gmail.com> <slrnjie1m9.2tp2.vadim_nuclight@kernblitz.nuclight.ipfw.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 30, 2012 at 10:08 PM, Vadim Goncharov <vadim_nuclight@mail.ru> wrote: > Hi Ermal Lu?i! > > On Mon, 30 Jan 2012 13:01:13 +0100; Ermal Lu?i wrote about '[PATCH] multi= ple 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 > > =A0 =A0 =A0 =A0if (oif && !(oif->if_flags & IFF_IPFW_FILTER)) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (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_co= ntext/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 progra= m. > 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 le= ast > /some/ people who need this. So the ipfw 'call'/'return' actions were alr= eady > 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-measu= res. > The only goal was to give people something right now, and see how much th= is > 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 pla= ce > - main unnamed chain is called from pfil as before > - rewrite ipfw & dummynet management from setsockopt() to netgraph messag= es > - completely rewrite ipfw dynamic rules to not conflict with multiple > =A0rulesets, as now they just jump to parent static rule (need to be more= like > =A0pf or iptables states). This item is hard but essential (you'll get a = mess > =A0jumping to another ruleset), and ipfw contexts don't handle ot > - while here, do other needed things, e.g. adding support for modules in = both > =A0kernel 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 maj= or > change than both ipfw2 and ipfw3 :) > > Due to various reasons in my private life, I was unable to do it in my sp= are > 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 specialize= d 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 =A0 =A0 =A0 mailto:vadim_nuclight@mai= l.ru > [Anti-Greenpeace][Sober FreeBSD zealot][http://nuclight.livejournal.com] > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" --=20 Ermal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPBZQG0gsi--ACj8exyAHTjT7yso0Kxh-A9YwdsKkabgJQXesA>