Oh my...
After lot of testing I think I am very close(I hope) to a working solution.
In short I got back to somehow close what David suggested regarding proxy arp
but I cannot find commarp package so for arp problem i just use static
arp entries
in different rdomain
em0 -> rdomain 1 + static arp entries that responds to switch port 20
with em0 hw address
em1 -> default rdomain that can communicate with switch port 21
So first em0 will resolve arp with his own address.
The idea is to see now how can I pass the incoming traffic from em0 through
em1 and be seen as switch as em1 since they have different rdomains.
Ideally would be something more simple to not introduce unnecessarily overhead
to cpu but what to say..this is what I have found till now.
On Thu, Jan 26, 2023 at 12:59 AM Tom Smyth wrote:
>
> Hi Christian,
>
> if you have Port 20 and 21 isolated from each other ... ie in the same
> protected port group 0 on the switch...
> and ports 1-19 in a spearate protected port group eg 1
> ports 1-19 can talk to either 20 or 21
> and ports 20-21 cannot talk to each other (loop avoidance)
>
> then in openBSD Bridge you can add em0 and em1 to the same protected port
> group eg 3
> you can do your filtering then...
> However... you have to contend with mac flaps on your OpenBSD Bridge (as
> broadcast traffic from clients will mean that client macs will be learned on
> both em0 and em1)
>
>
> anotther option and more granularly controlable ... to
> create 19 vlans...
>
> port 1 vlan1, access (untagged)
> port 2 vlan2 access (untagged)
> port 3 vlan3 access (untagged)
> ...
> ..
> port 19 vlan 19 access (untagged)
>
> make port 20 a trunk (tagged) port on the switch
>
> create 19 vlan interfaces in OpenBSD
> bridge them all together with port isolation or filtering you get around the
> hair pining etc... but your openbsd box will suffer if there is lots of
> broadcast traffic
> (copying frames to multiple ports can be challenging for your CPU)
>
> but if you are doing line rate stuff... you may just want to look at vlan
> maps / Vlan ACLs... (extend acls...) ... on the switch...
>
> one piece of advice... on this non standard layer 2 stuff (port
> isiolation on the switch and bridge is your friend always... in avoiding
> loops...
> watch the logs of the switch and cpu.. if the mac flaps are happinging you
> will see your switch logs (ususally ) moan about it
>
> watch your mac address table size and your hardware capacity on your
> switch...with this stuff... (know your switch hardware capacity and specs)
>
> i hope ths helps...
>
> On Wed, 25 Jan 2023 at 15:14, Cristian Danila wrote:
>>
>> Thank you so much Tom and David for giving me ideas where I can dig more.
>> Definitely it is a good start in this journey and I am researching more.
>> I have exact same situation with Wireless, for the moment all the clients are
>> isolated but I need to achieve the same, to filter between them.
>> I am evaluating also another idea(possible bad idea) like this:
>>
>> Switch having all the clients able to talk only with 2 ports: port 20
>> and 21 but port 20 and 21 cannot talk direct
>> Having BSD setup with two NIC's em0 and em1 as transparent filter: veb,
>> em0 connected to port 20
>> em1 connected to port 21
>>
>> In short the only possible way to pass frames from one device to
>> another is just through port 20 and 21
>>
>> I am aware about headache related to possible loops but I am curious
>> if it will work.
>>
>>
>> On Wed, Jan 25, 2023 at 2:33 PM Tom Smyth
>> wrote:
>> >
>> > Hey David...
>> > (I have learned so much from you over the years and used your gear so
>> > maybe I can give a lttle back on this one )
>> >
>> > "Correct use of Proxy arp" Gateway of layer 2 isolated network...
>> > clients cannot see or hear eachothers arp traffic or discovery traffic or
>> > other broadcast nasties
>> > so gateway knows everyones correct arp entry (because it can see everyone
>> > and everyone can see the gateway0
>> > gateway knows correct arp entries for 2 example clients clienta and clientb
>> >
>> > if client a wants to talk to client b ...they are isolated in layer 2
>> > ...so arp between them is not posible...
>> > enable proxy arp on gateway client a asks for clientbs mac address in an
>> > arp request
>> > gateway responds to client a with gateway mac address for clientb Ip
>> > address
>> > client a sends traffic for client b ip to gateway.mac .. gateway routes
>> > the traffic to client b ip via its connected route and correct arp address
>> > for client b
>> > client B asks for clienta mac address... in an arp request...
>> > gateway responds with an arp reply for clienta IP with its own mac address
>> > client b sends traffic to client a ip to the gateway mac address,
>> > gateway routes the traffic to client a via its connected route + correct
>> > arp entry for client a
>> >
>> > ---
>> > proxy arp is (kindof) useful in a lan gateway (LAN
