Date: Mon, 30 Jan 2012 21:08:25 +0000 (UTC) From: Vadim Goncharov <vadim_nuclight@mail.ru> To: freebsd-net@freebsd.org Cc: freebsd-hackers@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: [PATCH] multiple instances of ipfw(4) Message-ID: <slrnjie1m9.2tp2.vadim_nuclight@kernblitz.nuclight.ipfw.ru> References: <CAPBZQG32iyzkec4PG%2Bqay9bKfd0GiffKyRBapLkATKvHr7cVww@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > 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. > 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. 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@mail.ru [Anti-Greenpeace][Sober FreeBSD zealot][http://nuclight.livejournal.com]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?slrnjie1m9.2tp2.vadim_nuclight>