From: Balazs Scheidler <bazsi@balabit.hu>
To: Sven Schuster <schuster.sven@gmx.de>
Cc: Phil Oester <kernel@linuxace.com>,
netfilter-devel@lists.netfilter.org, netdev@vger.kernel.org,
shemminger@osdl.org
Subject: Re: [patch] RFC: matching interface groups
Date: Wed, 02 Aug 2006 09:04:29 +0200 [thread overview]
Message-ID: <1154502269.6241.11.camel@bzorp.balabit> (raw)
In-Reply-To: <20060801191805.GA28649@zion.homelinux.com>
On Tue, 2006-08-01 at 21:18 +0200, Sven Schuster wrote:
> Hi Phil,
>
> On Tue, Aug 01, 2006 at 11:46:55AM -0700, Phil Oester told us:
> > Since in this scenario userspace is able to determine ppp vs pptp,
> > could you not also do something like have an inbound_ppp and inbound_pptp
> > chain, then jump to the appropriate chain depending on type? If you
> > need per-interface rules, then create an inbound_pppX chain, populate
> > it with rules, then jump to that chain if -i pppX. In ip-down, just
> > delete the chain as well as the jump.
>
> if I understood Balazs correctly, one of the things he wanted to
> avoid is addition/deletion of iptables rules on every pppX interface
> up/down
Exactly.
> as this would require the complete chain (say, INPUT or
> OUTPUT) to be "downloaded" to userspace, modified and then again
> "uploaded" to the kernel. At least until iptables redesign to
> allow replacement/insertion/deletion of single rules is completed
> which if started at all will take quite some more time :-)
Iptables operates on a per-table basis, so it is not only the INPUT or
OUTPUT chain that needs to be down and uploaded, but the whole filter
table.
And in addition, in my humble opinion the iptables ruleset should be up
to the user to maintain, once some kind of automatism starts to
add/remove rules on the fly, it becomes more difficult to do other
changes to add independent rules to the table. For example the user
needs to save the current ruleset using iptables-save, then modify the
resulting file, and then load it again. If the ruleset is generated as
it happens with a lot of tools, this might not be so easy.
--
Bazsi
next prev parent reply other threads:[~2006-08-02 7:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-01 17:10 [patch] RFC: matching interface groups Balazs Scheidler
2006-08-01 18:29 ` Stephen Hemminger
2006-08-02 7:18 ` Balazs Scheidler
2006-08-01 18:46 ` Phil Oester
2006-08-01 19:18 ` Sven Schuster
2006-08-02 7:04 ` Balazs Scheidler [this message]
2006-08-02 9:01 ` Amin Azez
2006-08-03 12:57 ` Gerd v. Egidy
2006-08-03 4:08 ` Stephen J. Bevan
2006-08-03 19:08 ` Balazs Scheidler
2006-08-04 10:06 ` Patrick McHardy
2006-08-07 11:44 ` Balazs Scheidler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1154502269.6241.11.camel@bzorp.balabit \
--to=bazsi@balabit.hu \
--cc=kernel@linuxace.com \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@lists.netfilter.org \
--cc=schuster.sven@gmx.de \
--cc=shemminger@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox