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 tr!
yi!
> 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
> [EMAIL PROTECTED]
> http://www.math.leidenuniv.nl/mailman/listinfo/bridge
_______________________________________________
Bridge mailing list
[EMAIL PROTECTED]
http://www.math.leidenuniv.nl/mailman/listinfo/bridge

Reply via email to