Re: Bridging with 2 unidirectional vlans and one phys if

Jonathan Thibault wrote:
> Hello Zoilo,
>
> This sounds a lot like the problem I am having with putting two vlan 
> interfaces on a bridge.  If you ever find a solution be sure to tell me 
> what it was!
>   

Sure will do!

> What are the network card drivers you use?
>   

It is 8139too (Realtek 8139).

But I do not think that it has anything to do with the network card 
drivers. From inspecting tcpdump (monitoring on all interfaces) it is 
obvious that the ARP Request goes out via vlan223 (correct), but the 
Reply of course comes back on vlan200 (also correct) ... and from that 
moment on, all IP-traffic is now bridged to vlan200 (instead of 
vlan223), because that is where the MAC address replied ...

So I tried to establish a static ARP entry:
=> arp -s 192.168.22.254 00:11:22:33:44:55 -i vlan223

The ARP entry shows up correctly in the arp table, but it seems to be 
ignored: an ARP-request is sent out anyway for 192.168.22.254, in spite 
of the static ARP-entry, and I end up in the same situation.

Anybody know why the static ARP-entry is ignored?

Anybody know how to force that all IP-traffic be sent via vlan223, 
without ARP-interference?

TIA Z.

> Jonathan
>
> Zoilo Gomez wrote:
>   
>> Sorry for the poor subject title ... can't think of anything better at 
>> the moment.
>>
>>
>> On a machine with 2 ethernet interfaces eth0 and eth1, I am trying to 
>> use a bridge aux1 to connect 2 vlans on eth0 and the physical interface 
>> eth1 in the following setup:
>>
>> vconfig add eth0 vlan200
>> vconfig add eth0 vlan223
>>
>> brctl addbr aux1
>> brctl addif aux1 eth1
>> brctl addif aux1 vlan200
>> brctl addif aux1 vlan223
>>
>> ebtables -P INPUT DROP
>> ebtables -P OUTPUT DROP
>> ebtables -P FORWARD DROP
>>
>> ebtables -A FORWARD -i eth1 -o vlan223 -j ACCEPT
>> ebtables -A FORWARD -o eth1 -i vlan200 -j ACCEPT
>>
>> ebtables -A INPUT --log-prefix "INPUT"
>> ebtables -A OUTPUT --log-prefix "OUTPUT"
>> ebtables -A FORWARD --log-prefix "FORWARD"
>>
>> No iptables is installed; only ebtables.
>>
>>
>> The idea is to bridge all eth1-traffic over the 2 vlans, using vlan223 
>> to send-only data (TX), and using vlan200 to receive-only data (RX). The 
>> data from the 2 vlans is combined again further down the road, in a switch:
>>
>>
>>
>>                          |------|=== vlan223 (tx only) ==>|------|
>> PC <== eth1 (tx + rx) ==>| aux1 |                         |switch|<=> SERVER
>>                          |------|<== vlan200 (rx only) ===|------|
>>
>>
>>
>>
>> It works partially.
>>
>> If (with empty arp-cache) I do a ping from PC -> SERVER, I can follow 
>> the ARP-traffic using the VLANs exactly as I want: Request comes in via 
>> eth1 and goes out via vlan223 only, and Reply comes back through vlan200 
>> only, is bridged via eth1 and the PC's ARP-cache is updated with the 
>> correct information. Great!
>>
>> However, the then following ICMP request does come in on eth1, but never 
>> shows up on vlan223 ... it is bridged to vlan200 instead. This is 
>> apparently due to the ARP-reply coming back via vlan200 ...
>>
>> So I tried to add a static entry to the ARP-table on the machine hosting 
>> aux1, but this does not have any effect.
>>
>> What can I do to force the IP-traffic to go out via vlan223, i.e. to 
>> ignore or manipulate the ARP-reply over vlan200?
>>
>>
>>
>> Perhaps there is even a much better way to accomplish what I want to 
>> achieve, however I definitely need the unidirectional VLANs for reasons 
>> of traffic isolation (security) ...
>>
>>
>> TIA Z.
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Ebtables-user mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/ebtables-user
>>   
>>     
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Ebtables-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ebtables-user
>
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/