Source MAC address through bridged connection

Source MAC address through bridged connection

[Kelbel Junior]

Hi guys!

I have the following scenario:

Clients Network <------> Linux router <------> Mikrotik gateway
<------> INTERNET

Happens what the Mikrotik gateway controls the clients from the mac
address (joining an ip to an MAC address) and when i put the linux
router between they the control don't works.
I saw on the MK(mikrotik) the packets coming in with the MAC address
from the bridge, and this is a problem.

Exist some way to preserve the source mac through a bridged
connection, to continue seeing the mac address of the clients?

--

Att.
Kelbel Junior

Re: Source MAC address through bridged connection

[Rick Jones]

On Thu, 2011-05-19 at 12:52 -0300, Kelbel Junior wrote:
> Hi guys!
> 
> I have the following scenario:
> 
> Clients Network <------> Linux router <------> Mikrotik gateway
> <------> INTERNET
> 
> Happens what the Mikrotik gateway controls the clients from the mac
> address (joining an ip to an MAC address) and when i put the linux
> router between they the control don't works.
> I saw on the MK(mikrotik) the packets coming in with the MAC address
> from the bridge, and this is a problem.
> 
> Exist some way to preserve the source mac through a bridged
> connection, to continue seeing the mac address of the clients?

Is the device in the middle a router, or is it a bridge?  The
distinction is quite important.

Conceptually, a router does it's thing at layer three of the (in)famous
seven-layer model (*).  That means it only "preserves" layer three and
above.  Layer 2 and below is not preserved.

A bridge (or (multiport)switch, ignoring marktroid-speak about "L3
switching") does it's thing at layer two.  That means it preserves layer
two and above.  Layer 1 (physical) is not preserved.

rick jones

* there is also the nine-layer model
http://www.isc.org/store/logoware-clothing/isc-9-layer-osi-model-cotton-t-shirt

Re: Source MAC address through bridged connection

[Kelbel Junior]

Well, being more specific...
The computer between the clients and the Mikrotik (border gateway) is
a squid proxy operating in bridge, to intercept all traffic on the
port 80

2011/5/19 Rick Jones <rick.jones2@hp.com>:
> On Thu, 2011-05-19 at 12:52 -0300, Kelbel Junior wrote:
>> Hi guys!
>>
>> I have the following scenario:
>>
>> Clients Network <------> Linux router <------> Mikrotik gateway
>> <------> INTERNET
>>
>> Happens what the Mikrotik gateway controls the clients from the mac
>> address (joining an ip to an MAC address) and when i put the linux
>> router between they the control don't works.
>> I saw on the MK(mikrotik) the packets coming in with the MAC address
>> from the bridge, and this is a problem.
>>
>> Exist some way to preserve the source mac through a bridged
>> connection, to continue seeing the mac address of the clients?
>
> Is the device in the middle a router, or is it a bridge?  The
> distinction is quite important.
>
> Conceptually, a router does it's thing at layer three of the (in)famous
> seven-layer model (*).  That means it only "preserves" layer three and
> above.  Layer 2 and below is not preserved.
>
> A bridge (or (multiport)switch, ignoring marktroid-speak about "L3
> switching") does it's thing at layer two.  That means it preserves layer
> two and above.  Layer 1 (physical) is not preserved.
>
> rick jones
>
> * there is also the nine-layer model
> http://www.isc.org/store/logoware-clothing/isc-9-layer-osi-model-cotton-t-shirt
>
>



-- 

Att.
Kelbel Junior

Re: Source MAC address through bridged connection

[Ed W]

On 19/05/2011 17:11, Kelbel Junior wrote:
> Well, being more specific...
> The computer between the clients and the Mikrotik (border gateway) is
> a squid proxy operating in bridge, to intercept all traffic on the
> port 80

Then it's not a bridge because squid intercepts all packets and
generates new packets in response

However, there is an interesting new feature of squid, which was
discussed a couple of days ago, which allow squid to remark packets with
an outgoing firewall mark based on the incoming mark. With some thought
you might be able to leverage this to mark the packets in some way to
indicate they are valid to your next router (vlan tag, mac adjustment,
something else...)

Good luck

Ed W