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 for Android: free password hash cracker in your pocket

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

Message-ID: <20110712033943.GB616804@jupiter.n2.diac24.net>
Date:	Tue, 12 Jul 2011 05:39:44 +0200
From:	David Lamparter <equinox@...c24.net>
To:	Greg Scott <GregScott@...rasupport.com>
Cc:	David Lamparter <equinox@...c24.net>,
	Stephen Hemminger <shemminger@...tta.com>,
	netdev@...r.kernel.org, Lynn Hanson <LynnHanson@...anhills.org>,
	Joe Whalen <JoeWhalen@...anhills.org>
Subject: Re: Bridging behavior apparently changed around the Fedora 14 time

Hi --

First of all, I still can't find your kernel version in any of your
mails. Can you please repeat the uname -a output of the affected box?

Anyway,

On Mon, Jul 11, 2011 at 09:38:51PM -0500, Greg Scott wrote:
> > Why not proxy ARP?
> 
> I used to use proxy ARP until I got burned really badly with what proxy
> ARP really does - the NIC answers ARP requests (in proxy) for everyone
> and anyone that asks with its own MAC address.  Think about that - proxy
> ARP impersonates everyone and anyone on the LAN to which it's connected.

Yes. That's why you use
	ip neighbor add proxy 1.2.3.4 dev eth0
(for that to work, you need forwarding on, and the route for the host
must point to a different outbound device)

I agree that the proxy_arp /proc knob is pure evil. In my opinion it
should be removed in favour of "ip neighbor add proxy".

> > Why not use a VLAN?
> 
> Because I really don't need one.  Plus it doesn't matter anyway - the
> firewall can act as a router on a stick to go between my H.323 devices
> and private IP servers.  With or without VLANs makes no difference in
> this case.  

The VLAN saves you the SNAT on your clients traffic towards the NATed
services, because the traffic back from those NATed services goes
through the firewall, which will apply its conntrack entries.

Also, what you're doing is a case of _layer 3_ routing of packets that
arrive at an interface - br0 - back out to the same interface - br0. I'm
not excluding the possibility that the bridge code is broken, but my
nose tells me that your SNAT-DNAT setup is more likely to have gotten
broken.

Either way I still don't understand your setup. Are you using ebtables?
Where is your private IP that's facing towards the clients? Is there a
separate third DMZ network? What is $DMZ_IFACE?

(Posting your setup script is a noble thought completeness-wise, but
tbfh it's unreadable and maybe even the wrong parts. Please boil it
down to a few lines and please include the client direction...)

> - and now I think the problem is, bridging is supposed to turn on
> PROMISC mode and it didn't.  I had to do it by hand myself.

So it works when you switch the bridge members into PROMISC? (not the
bridge itself!)

> What I don't know yet is, is this a Fedora bug or a stock kernel bug?
> Is anyone from Red Hat following this email list?

I only know I haven't seen it anywhere, but my bridges are getting fewer
and fewer...

-David

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