netdev - 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-next>] [day] [month] [year] [list]

Message-ID: <925A849792280C4E80C5461017A4B8A2A040F0@mail733.InfraSupportEtc.com>
Date:	Mon, 11 Jul 2011 13:25:46 -0500
From:	"Greg Scott" <GregScott@...rasupport.com>
To:	<netdev@...r.kernel.org>
Cc:	"Lynn Hanson" <LynnHanson@...anhills.org>,
	"Joe Whalen" <JoeWhalen@...anhills.org>
Subject: Bridging behavior apparently changed around the Fedora 14 time

I ran into a strange situation - I am using a firewall set up as a
bridge.  Physical device eth1 is the private LAN side, eth0 is the
public Internet side.  I setup bridge br0 to bridge eth0 and eth1
together.  I need a bridge because this site has a couple of nodes on
the LAN side that need real public IP Addresses.  

This site also has a few web and ftp sites.  These are NATed behind the
firewall, but internal users need to see them the same way as the rest
of the world.  So I use some iptables SNAT and DNAT rules to make this
happen.  Device br0 has the relevant public IP Address(es) and then NATs
to the appropriate private IP Address(es).  The ruleset works and the
system has been up and running for several years.  

I recently replaced the old system with a new one running Fedora 14 and
that's when the weird behavior started.  

Now, when internal people try to look at those web/ftp sites using the
public IP Addresses, they get nowhere.  Unless I watch with tcpdump -
and then while I'm watching , all works as it should.  With some help,
we figured out the reason it works when watching with tcpdump - because
tcpdump puts the device being monitored into promiscuous mode.  

And, sure enough, when I do:
    ip link set br0 promisc on

everything works as it should.

Looking at "ip link show", it looks like bridge br0 takes on the MAC
address of physical NIC eth0.  But the internal LAN is connected to
physical eth1.  I wonder if this behavior is different than the older
version?  If the MAC Address for bridge br0 is different than the
physical device I'm actually connected to, I wonder if bridging "thinks"
I'm trying to hit a foreign MAC Address - especially since I'm doing
both SNAT and DNAT on the same packet?  

[root@...c-fw2011 ~]# ip link show eth1
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP qlen 1000
    link/ether 00:0d:88:31:d8:24 brd ff:ff:ff:ff:ff:ff
[root@...c-fw2011 ~]# ip link show eth0
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP qlen 1000
    link/ether 00:03:47:3a:59:79 brd ff:ff:ff:ff:ff:ff
[root@...c-fw2011 ~]#
[root@...c-fw2011 ~]# ip link show br0
5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc prio state
UNKNOWN
    link/ether 00:03:47:3a:59:79 brd ff:ff:ff:ff:ff:ff

[root@...c-fw2011 ~]# brctl show macs br0
bridge name     bridge id               STP enabled     interfaces
br0             8000.0003473a5979       no              eth0
                                                        eth1
Hmmmm - so a packet comes in on eth1, with a destination MAC Address
belonging to physical eth0.  So eth1 throws it away because it "thinks"
this is a foreign MAC Address?  But this all worked before, so what's
different?  Or were earlier bridges in promiscuous mode by default and
now they're not?  Have I stumbled across a new bridging bug?  Is the
best workaround to just put br0 into promiscuous mode?

Thanks

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