All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Eastep <teastep@shorewall.net>
To: Patrick McHardy <kaber@trash.net>
Cc: Netfilter Development Mailinglist
	<netfilter-devel@lists.netfilter.org>,
	Bart De Schuymer <bdschuym@pandora.be>
Subject: Re: RFC: Disable defered bridge hooks by default
Date: Tue, 11 Jul 2006 13:34:22 -0700	[thread overview]
Message-ID: <44B40B4E.6080206@shorewall.net> (raw)
In-Reply-To: <44AF200F.9000204@trash.net>

[-- Attachment #1: Type: text/plain, Size: 2079 bytes --]

Patrick McHardy wrote:
> Tom Eastep wrote:

>>
>> A similar approach is taken for locally-generated packets. There is a
>> single rule to direct all 'fw' to 'bar' traffic to the 'fw2bar' chain
>> ("fw" is the default name for the zone comprised of the local system):
>>
>> 	iptables -A OUTPUT -o <bridge> -m physdev \
>> 	--physdev-out <bar port> -j fw2bar
>>
>> As with forwarding, the fw2bar chain ends with a rule that enforces the
>> fw->bar policy.
>>
>> Predictably, the Shorewall rule:
>>
>> 	ACCEPT	fw	bar	tcp	25
>>
>> generates:
>>
>> 	iptables -A fw2bar -p tcp --dport 25 -j ACCEPT
>>
>> I see no sensible way to eliminate the --physdev-out usage in the OUTPUT
>> chain using ebtables/iptables and marking. What am I missing?
> 
> I'm a lazy reader, so I didn't follow this entirely. But:
> 
> "-i <bridge> -o <bridge> "
> 
> implies you're using this for purely bridged traffic. The feature
> we're going to remove only affects locally generated traffic exiting
> on a bridge device, in that case iptables _can't_ know the output
> port.

And that is the case that I'm concerned about.

> But you can do your iptables matching, mark matching packets
> and filter on the mark within ebtables.

I was afraid that's what you were going to suggest. If Shorewall was an
appliance that only supported a limited set of configurations, I could entertain
that approach; as it is, I'm not sure.

I'm going to issue a warning to my users that Shorewall support for
bridge/firewalls may be discontinued in the future. If in the next six months, I
can come up with code that is clean enough to go forward with, I'll rescind the
announcement.

So that I understand the playing field, --physdev-out will no longer be
supported out of the FORWARD and OUTPUT chains (all tables); is that correct?

Thanks,
-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

  parent reply	other threads:[~2006-07-11 20:34 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-04  9:26 RFC: Disable defered bridge hooks by default Patrick McHardy
2006-07-04  9:27 ` Patrick McHardy
2006-07-08  0:36   ` Tom Eastep
2006-07-08  3:01     ` Patrick McHardy
2006-07-10  9:56       ` Amin Azez
2006-07-11  8:28         ` Patrick McHardy
2006-07-11  9:33           ` Amin Azez
2006-07-11 20:34       ` Tom Eastep [this message]
2006-07-11 21:29         ` Patrick McHardy
2006-07-12 22:41           ` Tom Eastep
2006-07-13  7:35             ` Patrick McHardy
2006-07-13 14:11               ` Tom Eastep
2006-07-13 14:45                 ` Patrick McHardy
2006-07-13 15:31                   ` Tom Eastep
2006-07-15 14:32                     ` Tom Eastep
2006-07-19 14:21                     ` Patrick McHardy
2006-07-19 15:50                       ` Tom Eastep
2006-07-19 16:02                         ` Patrick McHardy
2006-07-13  9:56             ` Amin Azez
2006-07-12  6:16       ` Philip Craig
2006-07-13  0:20         ` Tom Eastep
2006-07-13  0:42           ` David Miller
2006-07-13  0:45             ` Tom Eastep
2006-07-13  9:45               ` Amin Azez
2006-07-13  7:31           ` Patrick McHardy
2006-07-13  7:46         ` Patrick McHardy
2006-07-13  8:12           ` Philip Craig
2006-07-13  8:36             ` Patrick McHardy
2006-07-13 14:11           ` Amin Azez
2006-07-13 14:50             ` Patrick McHardy
2006-07-13 15:29               ` Amin Azez
2006-07-19 16:36                 ` Patrick McHardy
     [not found]                   ` <44BE624E.5080307@ufomechanic.net>
2006-07-19 17:15                     ` Patrick McHardy
     [not found] <W8195318669268441152182124@nocme1bl6.telenet-ops.be>
2006-07-06 10:49 ` Patrick McHardy
2006-07-07  3:37 ` Patrick McHardy
  -- strict thread matches above, loose matches on Subject: below --
2006-07-07 10:17 bdschuym@pandora.be
2006-07-07 10:24 ` Patrick McHardy
2006-07-13 12:56 bdschuym@pandora.be
2006-07-13 14:38 ` Patrick McHardy

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=44B40B4E.6080206@shorewall.net \
    --to=teastep@shorewall.net \
    --cc=bdschuym@pandora.be \
    --cc=kaber@trash.net \
    --cc=netfilter-devel@lists.netfilter.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.