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: <20110711130729.607d461e@nehalam.ftrdhcpuser.net>
Date:	Mon, 11 Jul 2011 13:07:29 -0700
From:	Stephen Hemminger <shemminger@...tta.com>
To:	"Greg Scott" <GregScott@...rasupport.com>
Cc:	<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

On Mon, 11 Jul 2011 13:25:46 -0500
"Greg Scott" <GregScott@...rasupport.com> wrote:

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

Please provide more configuration information like:
  - NIC type
  - iptables and bridge and address configuration

Do you have reverse path filtering enabled/disabled?

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