netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Gerd v. Egidy" <lists@egidy.de>
To: netfilter-devel@lists.netfilter.org
Cc: Balazs Scheidler <bazsi@balabit.hu>,
	Sven Schuster <schuster.sven@gmx.de>,
	Phil Oester <kernel@linuxace.com>,
	netdev@vger.kernel.org, shemminger@osdl.org
Subject: Re: [patch] RFC: matching interface groups
Date: Thu, 3 Aug 2006 14:57:25 +0200	[thread overview]
Message-ID: <200608031457.26120.lists@egidy.de> (raw)
In-Reply-To: <1154502269.6241.11.camel@bzorp.balabit>

Hi,

> > > 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.

We faced a similar problem: we wanted to not only differentiate between ppp 
and pptp interfaces but even between different providers connected via ppp 
and pptp.

We ended up predefining all possible providers in the rules and differentiate 
between them using the ipt_condition module. This module is not very 
well-loved in the netfilter community but there are usecases like this where 
it comes in handy.

Maybe this is a solution for you too.

> > 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.

The problem with the current solution is not only speed and maintainability 
but also locking: if two device up/down events happen at the same time in 
this scenario, the tabels will become wrong until you develop some kind of 
userspace locking.

Kind regards,

Gerd

  parent reply	other threads:[~2006-08-03 12:57 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
2006-08-02  9:01       ` Amin Azez
2006-08-03 12:57       ` Gerd v. Egidy [this message]
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=200608031457.26120.lists@egidy.de \
    --to=lists@egidy.de \
    --cc=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;
as well as URLs for NNTP newsgroup(s).