Re: Bridge perculiarities

Further to this, I have removed all my kernel patches and I am
left with a vanilla 2.6.22.15 system and the mishaviour
mentioned in configuration 2 still persist.

Also I reconfigure the system without using a bridge ( but still
retaining mutipath routing with the one leg without NAT and one
leg with NAT configuration ), then I will not have this problem.

And so my limited conclusion now is that there is indeed some
interaction of bridge code which is causing this behaviour of
packets leaking out of IP netfilter SNAT rule !

By the way my configuration is on kernel 2.6.22.15. I am now
suspecting that it might be a day-one problem which existed
all along. I will probably try a newer kernel for next experiment.


----- Original Message ----- 
From: "Ming-Ching Tiew" <[email protected]>
To: <[email protected]>
Sent: Friday, January 04, 2008 11:25 AM
Subject: Bridge perculiarities


>
> I am writing to seek the opinions from the gurus here. My kernel
> is 2.6.22.4. The perculiarities comes in two different configurations :-
>
>
> Configuration 1
> ===========
> I am using ebtables to broute all traffic :-
>
>       ebtables -t broute -A BROUTING -i $INSIDE_DEV -p ipv4 \
>          -j redirect --redirect-target DROP
>       ebtables -t broute -A BROUTING -i $OUTSIDE_DEV -p ipv4 \
>         -j redirect --redirect-target DROP
>
> On the left side of the bridge, I have a machine A with 192.168.128.2
> and on the right side of the bridge, I have a machine C with 192.168.128.3,
> and the bridge B itself is 192.168.128.1.
>
> On the machine B ( bridge itself ) and C I have ssh server running on port 22.
>
> When the machine A makes a ssh connection to C, it's however logs into
> the bridge B instead. It's not limited to ssh port, any processes listening
> to any port on bridge B, will hijack the connections to machine C.
>
> What have I done wrong ?
>
>
> Configuration 2
> ===========
> Instead of brouting all traffic, I will now broute only the http traffic this way :-
>
>       ebtables -t broute -A BROUTING -i $INSIDE_DEV -p ipv4 \
>         --ip-protocol tcp --ip-destination-port 80 -j redirect --redirect-target
DROP
>       ebtables -t broute -A BROUTING -i $OUTSIDE_DEV -p ipv4 \
>         --ip-protocol tcp --ip-source-port 80 -j redirect --redirect-target DROP
>
> which means none port 80 traffic will be bridged instead of broute.
> ( This might not be relevent to the observation below ).
>
> At the same time, on the br0 interface, there is a IP configured and
> there is an interface to the internet via NAT.
>
> I have a LAN machine A using that the bridge br0 IP as a default gateway.
>
> However I noticed that at a very high % of time, the ping packet from
> a LAN machine A with the private source IP gets into the internet without
> being nattted. The strange thing is that, it is not consistent. Sometimes
> it's natted, sometimes it's not. It means the SNAT rule in the nat table
> POSTROUTING chain is sometimes skipped.
>
> I am wondering if anyone observed this, or it's due to some of the
> patches I applied.
>
> Regards


--------------------------------------------
Important Warning! 

*************************** 

This electronic communication (including any attached files) may contain confidential and/or legally privileged information and is only intended for the use of the person to whom it is addressed. If you are not the intended recipient, you do not have permission to read, use, disseminate, distribute, copy or retain any part of this communication or its attachments in any form. If this e-mail was sent to you by mistake, please take the time to notify the sender so that they can identify the problem and avoid any more mistakes in sending e-mail to you. The unauthorised use of information contained in this communication or its attachments may result in legal action against any person who uses it.


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace