[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-bridge
Subject:    Re: [Bridge] 2.4 bridge/filter/NAT
From:       Lennert Buytenhek <buytenh () gnu ! org>
Date:       2002-02-18 0:58:17
[Download RAW message or body]

Hi,

DNAT in its current form rewrites the source ethernet address on
packets, because it has to use the bridge host's IP stack to find
a new destination ethernet address for the new destination IP
address, and the only API exported to us has the side-effect of
mangling the source address.  There's not much we can do about
this, I'm afraid!  What you could try is marking the packets in
the mangle/PREROUTING chain, and filtering on the mark value
later.  It's somewhat of a hack, I agree, but the best we can do
I'm afraid :/


cheers,
Lennert


On Sun, Feb 17, 2002 at 02:47:02PM -0600, Logan Freeman wrote:

> Ok, here's a puzzle if you have time.
> 
> I've used the old bridging stuff on a 2.2 kernel JUST doing bridging and filtering \
> with no trouble.  I then moved to the 2.4 kernels on newer hardware and all was \
> well.  I recently added a couple of NICs to the machine that does the bridging to \
> run a couple of 'fake' subnets on 192.168.0.0/24 and 192.168.1.0/25 (long story, \
> don't ask).  The general idea was to NAT the fake subnets onto the IP of the bridge \
> (I've got the 2 bridging cards without IPs and the virtual br0 interface with one). \
> Well, I put wireless on one of the new interfaces and wanted to filter it in the \
> FORWARD chain (just like I do on the bridging interface - and how I do at home \
> though it doesn't bridge) based on MAC addresses of 'approved' cards rather than \
> something like destination IP, etc.  I put the MACs of the wireless cards in \
> question into my iptables script and it won't match them.  It just fails out of the \
> iptables checks like it isn't one of those MACs.  Well crap.  So I play for a long \
> time tryi! ng different things and I finally luck out and figure out that if I \
> allow the MAC of the bridge interface (which it grabs from the eth0 card in the \
> bridge) it matches.  So, all my packets from the 2 non-bridged NICs are getting \
> their MACs rewritten BEFORE the FORWARD chain checks.  Bug?  Feature? 
> Basically, am I missing something or does that sounds right to your design of the \
> hooks in the kernel?  If so, is there a way to fix this or is this the way it has \
> to be for some other reason since I'd guess this is a fairly rare need compared to \
> the desire for an invisible filter without an IP.  Thanks for your time. 
> Logan Freeman '00
> Network Administrator
> The Association of Former Students
> Texas A&M University
> (979) 845-7514
> www.AggieNetwork.com
> 
> Solution to all network problems:
> sed -e 's/windows/linux/g' -e 's/novell/linux/g'
> 
> _______________________________________________
> Bridge mailing list
> Bridge@math.leidenuniv.nl
> http://www.math.leidenuniv.nl/mailman/listinfo/bridge


[prev in list] [next in list] [prev in thread] [next in thread]