Re: OpenBSD as a transparent switch filter
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
Re: OpenBSD as a transparent switch filter
Hi Tom, I am just about trying your suggestion but I'm confused regarding one thing. You mentioned " then in openBSD Bridge you can add em0 and em1 to the same protected port group eg 3" Do you mean em0 and em1 should be isolated by each other? Then how is supposed to communicate em0 with em1? Thank you. On Thu, Jan 26, 2023, 00:59 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 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
Re: OpenBSD as a transparent switch filter
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 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 wrote: > >> > >> > >> > >> > On 25 Jan 2023, at 09:47, Tom Smyth > 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
Re: OpenBSD as a transparent switch filter
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 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 wrote:
>>
>>
>>
>> > On 25 Jan 2023, at 09:47, Tom Smyth 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 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 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
>>
Re: OpenBSD as a transparent switch filter
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 wrote:
>
>
> > On 25 Jan 2023, at 09:47, Tom Smyth
> 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 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 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 PORT2PORT3 PORT 20
> >>> | | |_|
> >>> | |_ |
> >>> |__ |
> >>> PHISICAL SWITCH DEVICE |
> >>> ---|
> >>> |
> >>> |
> >>> |
> >>> OPEN BSD BOX
> >>>
> >>>
> >>> Thank you.
> >>>
> >>>
> >>>
Re: OpenBSD as a transparent switch filter
> On 25 Jan 2023, at 10:03, Martin Schröder wrote: > > Am Mi., 25. Jan. 2023 um 00:45 Uhr schrieb David Gwynne : >> 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. > > But arp only works for vintage-ip. You mean IP-classic? I’d argue it should be less than the majority of traffic on the Internet before we call it vintage. The principle could be applied to v6 as well.
Re: OpenBSD as a transparent switch filter
Am Mi., 25. Jan. 2023 um 00:45 Uhr schrieb David Gwynne : > 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. But arp only works for vintage-ip. Best Martin
Re: OpenBSD as a transparent switch filter
> On 25 Jan 2023, at 09:47, Tom Smyth 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 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 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 PORT2PORT3 PORT 20
>>> | | |_|
>>> | |_ |
>>> |__ |
>>> PHISICAL SWITCH DEVICE |
>>> ---|
>>> |
>>> |
>>> |
>>> OPEN BSD BOX
>>>
>>>
>>> Thank you.
>>>
>>>
>>> On Tue, Jan 24, 2023 at 1:43 PM Tom Smyth
>>> 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 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
>
Re: OpenBSD as a transparent switch filter
Hi David is that like a local proxy arp type setup (on typical
networking gear) .. ?
On Tue, 24 Jan 2023 at 23:45, David Gwynne 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 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 PORT2PORT3 PORT 20
> >| | |_|
> >| |_ |
> >|__ |
> > PHISICAL SWITCH DEVICE |
> > ---|
> > |
> > |
> > |
> > OPEN BSD BOX
> >
> >
> > Thank you.
> >
> >
> > On Tue, Jan 24, 2023 at 1:43 PM Tom Smyth
> > 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 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.
Re: OpenBSD as a transparent switch filter
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 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 PORT2PORT3 PORT 20
>| | |_|
>| |_ |
>|__ |
> PHISICAL SWITCH DEVICE |
> ---|
> |
> |
> |
> OPEN BSD BOX
>
>
> Thank you.
>
>
> On Tue, Jan 24, 2023 at 1:43 PM Tom Smyth
> 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 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.
>
Re: OpenBSD as a transparent switch filter
I agree with Claudio re Hairpin issue... perhaps an alternate setup would be to use 2 vlans on the switch on the uplink of the openbsd box (to avoid the hair pin on a physical interface) but care needs to be taken when bridging between the two vlans as 2x mac table usage will occur ... ie mac address on one device may be present in two vlans (if you have a filtering bridge between the two vlans ) and isolation is turned off at any stage... ( I have been badly caught out on this when aggregating n vlans ... n bridged vlans x (original mactable usage ) = new mac address table size Hope this helps... On Tue, 24 Jan 2023 at 12:24, Claudio Jeker wrote: > > On Tue, Jan 24, 2023 at 11:43:08AM +, Tom Smyth 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... > > > > The problem is not veb(4) vs bridge(4) (both should work and I would > suggest you try to stay away from brigde(4)). The problem is the hairpin > on the single interface to the switch. AFAIK neither veb(4) nor bridge(4) > will send back a packet on the same port it was received on. Doing so > can result in packet loops. > > > > On Tue, 24 Jan 2023 at 11:29, Cristian Danila 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. > > > > -- > :wq Claudio > -- Kindest regards, Tom Smyth.
Re: OpenBSD as a transparent switch filter
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 PORT2PORT3 PORT 20 | | |_| | |_ | |__ | PHISICAL SWITCH DEVICE | ---| | | | OPEN BSD BOX Thank you. On Tue, Jan 24, 2023 at 1:43 PM Tom Smyth 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 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.
Re: OpenBSD as a transparent switch filter
On Tue, Jan 24, 2023 at 11:43:08AM +, Tom Smyth 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... > The problem is not veb(4) vs bridge(4) (both should work and I would suggest you try to stay away from brigde(4)). The problem is the hairpin on the single interface to the switch. AFAIK neither veb(4) nor bridge(4) will send back a packet on the same port it was received on. Doing so can result in packet loops. > On Tue, 24 Jan 2023 at 11:29, Cristian Danila 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. > -- :wq Claudio
Re: OpenBSD as a transparent switch filter
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 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.
OpenBSD as a transparent switch filter
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
