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 <tom.sm...@wirelessconnect.eu> 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 interface only) were the 
> IT admin hasnt a handle on routing and gives vpn clients an IP in the same 
> range as the Lan in the office..
> Proxy arp allows the gateway to respond to arp requests for the vpn client 
> IP... (but it is no substitute for teaching an IT person how to route and 
> design/ number networks)
>
> -------incorrect use of proxy arp-------------
> EVERYWHERE ELSE ... (sorry for shouting )
>
> ps I hate proxy arp ... but it is useful in allowing client - client 
> communications while minimising broadcast waste of bandwidth (on large 
> wireless access networks)
>
>
>
>
> On Tue, 24 Jan 2023 at 23:53, David Gwynne <da...@gwynne.id.au> wrote:
>>
>>
>>
>> > On 25 Jan 2023, at 09:47, Tom Smyth <tom.sm...@wirelessconnect.eu> wrote:
>> >
>> > Hi David is that like a local proxy arp type setup (on typical
>> > networking gear) .. ?
>>
>> I’ve never had a clear idea about what proxy ARP is, and the only time it 
>> comes up in converstaion is when people complain about problems it causes. 
>> Do you have a definition of what you think it means before I say yes or no?
>>
>> >
>> > On Tue, 24 Jan 2023 at 23:45, David Gwynne <da...@gwynne.id.au> wrote:
>> >>
>> >> I think you can do this on OpenBSD with 
>> >> https://github.com/eait-itig/commarp and just routing on em0. I don’t 
>> >> think any layer 2 things like bridge or veb are needed, and probably 
>> >> won’t work anyway because as Claudio said, they don’t want to hairpin 
>> >> anyway.
>> >>
>> >> That code doesn’t have any manpages unfortunately. commarp wants a config 
>> >> file saying which interface it should run on and which IPs it should 
>> >> intercept ARP for. eg:
>> >>
>> >> $ cat /etc/commarp.conf
>> >> interface em0 {
>> >>        allow 192.168.1.16 - 192.168.1.254
>> >> }
>> >>
>> >> There’s no point rewriting ARP requests for the IP your router is using 
>> >> on that subnet, or carp addresses on that subnet, etc.
>> >>
>> >>
>> >>> On 24 Jan 2023, at 22:16, Cristian Danila <clau...@postmail.ro> wrote:
>> >>>
>> >>> HI Tom,
>> >>>
>> >>> I am familiar with options you mentioned, veb, bridge and isolated ports.
>> >>> I am having another transparent filter based of veb also I am aware about
>> >>> protected members but my use case is different.
>> >>>
>> >>> Let me try to explain maybe with different words.
>> >>> OpenBSD box is having only one cable input, so what would be the
>> >>> benefit of having protected members?
>> >>> Protected members are isolating the communication between members of a
>> >>> bridge, in my case
>> >>> I have only one NIC, so if a bridge would be helpful, I can have a
>> >>> bridge with single member,
>> >>> therefore isolating that member from who?
>> >>> OpenBSD box has only one wire connected to a physical switch, so it
>> >>> can communicate with all members
>> >>> of the switch, but the physical switch itself do not permit
>> >>> communication between members as explained.
>> >>> So it is a desire that OpenBSD box is the one that is making possible
>> >>> communication between different
>> >>> members of the switch through same wire.
>> >>>
>> >>> Let me try to draw it, I hope will help more
>> >>>
>> >>> DEVICE1 DEVICE2 DEVICE3
>> >>>    |               |              |
>> >>>    |               |              |
>> >>> -----------------------------------------------------------
>> >>> PORT1     PORT2    PORT3     PORT 20
>> >>>   |               |              |_________|
>> >>>   |               |_________________ |
>> >>>   |__________________________ |
>> >>> PHISICAL SWITCH DEVICE          |
>> >>> ---------------------------------------------------|--------
>> >>>                                                  |
>> >>>                                                  |
>> >>>                                                  |
>> >>>                                      OPEN BSD BOX
>> >>>
>> >>>
>> >>> Thank you.
>> >>>
>> >>>
>> >>> On Tue, Jan 24, 2023 at 1:43 PM Tom Smyth <tom.sm...@wirelessconnect.eu> 
>> >>> wrote:
>> >>>>
>> >>>> Hello Cristian,
>> >>>> if you want to filter on layer 2 ... you would need to use Bridge....
>> >>>> have a look at  man ifconfig(8)
>> >>>> bridge filter rules can be added to ports in the bridge...
>> >>>> you can also tag traffic in bridge filter rules and then use PF to
>> >>>> filter them...
>> >>>>
>> >>>> but if your objective is to isolate ports from each other.. this can
>> >>>> be achieved with protected port groups...
>> >>>> again check out ifconfig (8)
>> >>>> TLDR version bridge ports in the same protected port group are
>> >>>> isolated from each other...
>> >>>> If port isolation if all your looking for (no other detailed filtering
>> >>>> ) if (im not sure) veb(4) supports protected ports...then this would
>> >>>> be faster...
>> >>>> but to my shame I have not tried out veb(4)
>> >>>>
>> >>>> I hope this is of some use...
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Tue, 24 Jan 2023 at 11:29, Cristian Danila <clau...@postmail.ro> 
>> >>>> wrote:
>> >>>>>
>> >>>>> Hello
>> >>>>>
>> >>>>> I have a more difficult task that I would like to solve with OpenBSD
>> >>>>> and I would really
>> >>>>> appreciate any ideas if it is possible to achieve such.
>> >>>>>
>> >>>>> I have:
>> >>>>> - one OpenBSD box with one Ethernet port
>> >>>>> - one big switch with multiple devices connected
>> >>>>>
>> >>>>> All switch ports are isolated by each other with one exception:
>> >>>>> - All ports can communicate with only one Ethernet port(let's say port 
>> >>>>> 20)
>> >>>>>
>> >>>>> Now what i would like to achieve is to connect an Ethernet cable 
>> >>>>> between
>> >>>>> OpenBSD box and port 20 of the switch, and make OpenBSD a transparent
>> >>>>> filtering hub.
>> >>>>>
>> >>>>> So I need OpenBSD box to be a transparent bridge and filter between
>> >>>>> clients of the switch.
>> >>>>>
>> >>>>> Can anybody suggest a point where I can think about?
>> >>>>> I was thinking initially to add the nic(em0) to veb0 then with link1
>> >>>>> achieve L3 filtering but
>> >>>>> definitely I think I miss something important.
>> >>>>> I am open to research everything is needed for it but I miss a
>> >>>>> starting point and I would
>> >>>>> really appreciate any hint.
>> >>>>>
>> >>>>> Kind regards,
>> >>>>> Claudiu
>> >>>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Kindest regards,
>> >>>> Tom Smyth.
>> >>>
>> >>
>> >
>> >
>> > --
>> > Kindest regards,
>> > Tom Smyth.
>>
>
>
> --
> Kindest regards,
> Tom Smyth.

Reply via email to