Date: Tue, 31 Jan 2012 01:21:23 -0800 From: Julian Elischer <julian@freebsd.org> To: =?ISO-8859-1?Q?Ermal_Lu=E7i?= <eri@freebsd.org> Cc: vadim_nuclight@mail.ru, freebsd-net@freebsd.org, freebsd-hackers@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: [PATCH] multiple instances of ipfw(4) Message-ID: <4F27B293.5000605@freebsd.org> In-Reply-To: <CAPBZQG0gsi--ACj8exyAHTjT7yso0Kxh-A9YwdsKkabgJQXesA@mail.gmail.com> References: <CAPBZQG32iyzkec4PG%2Bqay9bKfd0GiffKyRBapLkATKvHr7cVww@mail.gmail.com> <slrnjie1m9.2tp2.vadim_nuclight@kernblitz.nuclight.ipfw.ru> <CAPBZQG0gsi--ACj8exyAHTjT7yso0Kxh-A9YwdsKkabgJQXesA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1/31/12 12:53 AM, Ermal Luçi wrote: > 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] 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 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@mail.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" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F27B293.5000605>