netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bart De Schuymer <bdschuym@pandora.be>
To: Florian Westphal <fw@strlen.de>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: RFC: bridge netfilter vlan device name resolution
Date: Tue, 03 Apr 2012 14:18:12 +0200	[thread overview]
Message-ID: <4F7AEA84.3070004@pandora.be> (raw)
In-Reply-To: <20120402092516.GA24416@Chamillionaire.breakpoint.cc>

Op 2/04/2012 11:25, Florian Westphal schreef:
> Bart De Schuymer<bdschuym@pandora.be>  wrote:
>> I don't like approach #2: it will break existing firewall 
>> configurations and I really don't see a reason why we would change 
>> the network device to a non-bridge device (br0.1 isn't a bridge). 
>> Approach #1 can be achieved without code changes with the nfmark 
>> field as shown below. You can filter on the vlan id in iptables by 
>> using the nfmark field intelligently, see e.g. 
>> http://ebtables.sourceforge.net/examples/basic.html#ex_network_separation 
>
> However, the REDIRECT target won't work with vlans on the bridge,
> because skb->dev points to the bridge instead of the vlan, and thus
> the REDIRECT target fails to get the ip address.

Can't you use the DNAT target instead? If you have multiple vlan devices 
on top with multiple IP addresses, you can use the nfmark value to 
determine the destination IP address.
> Would at least the PRE_ROUTING part of my patch be acceptable to make
> REDIRECT work?

No, for the same reasons as stated before... What would be acceptable is 
an extension that allows to specify which input device to give to 
iptables. Perhaps for your use case, another flag in 
|/proc/sys/net/bridge/ |that allows turning this feature on (off by 
default) would be nice. The behaviour should then be like your original 
idea and not restricted to only the PREROUTING case described above. A 
name for the flag that comes to mind is |bridge-nf-pass-vlan-input-device.|

Best regards,
Bart

-- 
Bart De Schuymer
www.artinalgorithms.be


  reply	other threads:[~2012-04-03 12:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-26 20:21 RFC: bridge netfilter vlan device name resolution Florian Westphal
2012-03-26 20:23 ` [RFC PATCH] netfilter: bridge: change indev name to vlan if vlan tag present Florian Westphal
2012-03-27 15:37   ` Pablo Neira Ayuso
2012-03-27 17:34 ` RFC: bridge netfilter vlan device name resolution Bart De Schuymer
2012-03-27 20:19   ` Florian Westphal
2012-04-02  9:25   ` Florian Westphal
2012-04-03 12:18     ` Bart De Schuymer [this message]
2012-04-03 20:47       ` Florian Westphal

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=4F7AEA84.3070004@pandora.be \
    --to=bdschuym@pandora.be \
    --cc=fw@strlen.de \
    --cc=netfilter-devel@vger.kernel.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).