netdev - RE: Bridging behavior apparently changed around the Fedora 14 time

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <925A849792280C4E80C5461017A4B8A2A0414B@mail733.InfraSupportEtc.com>
Date:	Fri, 22 Jul 2011 01:20:13 -0500
From:	"Greg Scott" <GregScott@...rasupport.com>
To:	<netdev@...r.kernel.org>
Cc:	"Lynn Hanson" <LynnHanson@...anhills.org>,
	"Joe Whalen" <JoeWhalen@...anhills.org>,
	"Graham Parenteau" <adfgrahame1@...il.com>,
	"David Lamparter" <equinox@...c24.net>
Subject: RE: Bridging behavior apparently changed around the Fedora 14 time

Hang on a second - David, I think you're trying to tell me I'm the
problem.  Maybe so...

I send a frame in on eth1/br0.  It traverses a bunch of ebtables and
iptables DNAT and SNAT rules and then wants to come back out on
eth1/br0.  But this is both a bridge and a router, and trying to
remember my bridge basics - as I recall, bridges might not want to
forward frames back out the same physical interface they came in on.  

After running this frame/packet through a gauntlet of ebtables/iptables
rules and NATing the snot out of the IP packet inside the frame, I
wonder if it's still the same layer 2 frame when it gets ready to come
back out on eth1?  Even though NAT changed the layer 3 routed packet IP
info, I wonder if it's still the same layer 2 datalink frame?  So the
bridge says, "No way Jose, that's the same physical interface you came
in on" and drops it.  

And then turning on promisc mode makes the bridge less picky and it
happily forwards all frames everywhere.  

Is this what you've been trying to tell me and I'm too thickheaded to
get it?

If so, to work around the problem, I was reading about some ebtables
broute ACCEPT/DROP targets that are apparently named badly - DROP
apparently tells the bridge to route the packet instead of bridging the
frame, while ACCEPT tells the bridge to bridge it.  Should I be looking
in this direction?

But thinking about this some more - there are cases, such as cascaded
switches, or hubs behind a switch, where you want a bridge to forward
frames back out the same interface.  Well . . . maybe.  There's still
something about forwarding out the same interface a frame comes in on
that's bugging me.

- Greg

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html