From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 1 14:10:54 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECAF6106564A for ; Wed, 1 Feb 2012 14:10:54 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 99CD88FC08 for ; Wed, 1 Feb 2012 14:10:53 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Rsatf-0006Ui-N0 for freebsd-hackers@freebsd.org; Wed, 01 Feb 2012 15:10:51 +0100 Received: from broadband-77-37-240-109.nationalcablenetworks.ru ([77.37.240.109]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Feb 2012 15:10:51 +0100 Received: from vadim_nuclight by broadband-77-37-240-109.nationalcablenetworks.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Feb 2012 15:10:51 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Vadim Goncharov Date: Wed, 1 Feb 2012 14:10:42 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 184 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: broadband-77-37-240-109.nationalcablenetworks.ru X-Comment-To: Ermal Lu?i User-Agent: slrn/0.9.9p1 (FreeBSD) Cc: freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: [PATCH] multiple instances of ipfw(4) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 14:10:55 -0000 Hi Ermal Lu?i! On Tue, 31 Jan 2012 09:53:30 +0100; Ermal Lu?i wrote about 'Re: [PATCH] multiple instances of ipfw(4)': >>> 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 .... So one must need change context between invocations of ipfw? Not very user friendly and subject to races. How are you going to fix them? >>> 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. Agreed that it is not easy, but that is just something available *right now* already allowing to simplify some messy rulesets with skipto's. It was done as a short-term solution until something more powerful will be done. >> 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. Yes, it's easier to get feedback on what people need when at least something was presented (implemented) to them. >> 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 :) > 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. No, point is not in design, but in usability first (perhaps my English was too bad?). Design here is just a way to handle desired usability. How this will be for user: ipfw chain mychain create ipfw chain common create default-policy allow ipfw chain lanusers create ipfw chain mychain add 200 ... ipfw chain mychain delete 300 ... ipfw chain mychain destroy ipfw add 100 call common ip from any to any # call from main ruleset ipfw ng_bpf mypktbody create ipfw ng_bpf mypktbody config proto udp and udp[42:4]=0x01020304 ipfw add 200 deny ngmatch mypktbody ipfw bind mychain to interface em0 direction out ipfw bind lanusers to interface vlan100 ipfw pfil-order move ipfilter bottom Hope that's enough user-intuitive. And netgraph-based design here is very straightforward: for examples above, you just create netgraph nodes named "ipfwmychain", "ipfwcommon", etc., then do send NGM_IPFW_ADD message to the node with name of appropriate "chain" keyword, or main ng_ipfw if none. Netgraph here is not a stack, but a clean alternative to hack raw_ip.c for new setsockopt()'s (not very modular) or for user to be able manually assign node in complex configuration (usually the /sbin/ipfw will do). Aside that, netgraph messages do provide clean versioning - it was hard to keep compatible interfaces when ABI changed in 8.2. There is no more Netgraph or even stacks in this stacks, it just suits very well :) > Though its a matter of preference and how much work its needed to > accomplish this! Unfortunatelly, no. Here is the problem with dynamic rules which is the main: - suppose you have router with interfaces X, Y. - you have TCP/UDP session from A to B, incoming on X and leaving through Y - you have per-interface rules, for X on input, for Y on output Then, if a packet entered via iface X, and there is a *state* (dynamic rule) there, then, whatever you write in rules for Y - the first keep-state will accept packet, no matter what rule, it will be accepted. You can try to expoit the fact that in ipfw, dynamic rule just jumps to parent rule's action part, and, if that was "skipto", continues on a static ruleset (where it could be checked, which interface). But this becomes unmaintainable mess even on 3-4 interfaces (it's like assembly language programming), and if you have hundreds of ifaces, you may encounter there is not enough numbers in 65536 to handle all X*Y combinations (not all ifaces need be stateful) even if config is somehow generated automatically. There is company which really comes up to such situation, and ipfw context can't handle it. Then you encounter dynamic rules must be redesigned. Given another users' polls, they do need something like iptables chains, for maintenance. Then you look at hacks present in ipfw code from past, and eventually come up to something like I described earlier - another design which also allows several other good new features. >> 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. > But surely nothing should stop both ways. I wanted to say, don't be afraid or upset that ipfw context are not generic enough for broader needs. If that allows to solve your practical problems right now (relatively fast), then do it, it is good, it's better than wait for a more comprehensive solution. I've implemented "ipfw call" from the exactly the same thinking. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Anti-Greenpeace][Sober FreeBSD zealot][http://nuclight.livejournal.com]