From owner-freebsd-ipfw@FreeBSD.ORG Tue Jan 31 08:53:31 2012 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 736241065677; Tue, 31 Jan 2012 08:53:31 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 172038FC14; Tue, 31 Jan 2012 08:53:30 +0000 (UTC) Received: by iaeo4 with SMTP id o4so10620269iae.13 for ; Tue, 31 Jan 2012 00:53:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EqXGhg4V/rlM5rzkuz1bpB1/onweZIQ8GUV+rTL+1WM=; b=OaG8+W7gGxNU3L3ohYS9bZ5RJk7YJZvxy/cxe/V2ms33HFoZc3ksAGi3v/fVQcIBZD oDV7DEH5MAdxJGJ0peNzB4vET7MR5MO9/1+8OUvb8Z7+lo24FgAVcrIIoBxo9JBhpRYc LSKsPNjYpl7Puf3/LjllK6ojHhm27ib+xcC9c= MIME-Version: 1.0 Received: by 10.50.88.163 with SMTP id bh3mr21138643igb.0.1328000010299; Tue, 31 Jan 2012 00:53:30 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.231.134.198 with HTTP; Tue, 31 Jan 2012 00:53:30 -0800 (PST) In-Reply-To: References: Date: Tue, 31 Jan 2012 09:53:30 +0100 X-Google-Sender-Auth: zgwPPma5VZs-sQfTlSf4HGDFMZQ Message-ID: From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: vadim_nuclight@mail.ru Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [PATCH] multiple instances of ipfw(4) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 08:53:31 -0000 On Mon, Jan 30, 2012 at 10:08 PM, Vadim Goncharov 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