Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 27 Oct 2018 19:26:41 +0300
From:      Victor Gamov <vit@otcnet.ru>
To:        freebsd-net@freebsd.org
Subject:   Re: ipfw on bridge connecting vlans
Message-ID:  <49c4193a-d38c-eff8-3ab8-25b103c2dcba@otcnet.ru>
In-Reply-To: <9b8d8c04-8e3e-b148-8a08-135d6ac1785d@grosbein.net>
References:  <36cd661e-ca54-be94-fd64-01ee768d5053@otcnet.ru> <9b8d8c04-8e3e-b148-8a08-135d6ac1785d@grosbein.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On 27/10/2018 18:44, Eugene Grosbein wrote:
> 27.10.2018 22:16, Victor Gamov wrote:
>>
>> Hi All
>>
>> I have some misunderstanding how ipfw work with VLAN and bridge
>>
>> I have following config
>>
>>
>>          bridge2
>>        ------------
>>       /      |     \
>>      /       |      \
>>     /        |       \
>> vlan200  vlan300  vlan400
>> (igb0)    (igb0)   (igb1)
>>
>>
>> =====
>> net.link.bridge.ipfw: 1
>> net.link.bridge.allow_llz_overlap: 0
>> net.link.bridge.inherit_mac: 0
>> net.link.bridge.log_stp: 0
>> net.link.bridge.pfil_local_phys: 0
>> net.link.bridge.pfil_member: 0
>> net.link.bridge.ipfw_arp: 1
>> net.link.bridge.pfil_bridge: 0
>> net.link.bridge.pfil_onlyip: 0
>>
>> net.link.ether.ipfw=1
>> =====
>>
>>
>> I need to allow some multicast from some vlans, block other multicast and forward allowed multicast into other vlans
> 
> Your ruleset needs to differentiate packets based on name of incoming bridge member
> but you forgot to enable net.link.bridge.pfil_member=1. Enable it.
> 
> Also note that change of net.link.bridge.ipfw from 0 to 1 disables
> net.link.bridge.{pfil_member|pfil_onlyip|pfil_bridge} but you are allowed
> to enable them after.
> 
> net.link.bridge.pfil_member=1 makes frames enter ruleset as incoming from bridge member, zero disables this pass.
> 
> net.link.bridge.ipfw=1 makes frames enter ruleset again as incoming from bridge interface itself
> without distinction of bridge member, and for forwarded frames enter ruleset one more time as outgoing from the bridge itself.
> 
> And frame enters ruleset one MORE time as outgoing from bridge member if net.link.bridge.pfil_member=1.

Hi Eugene,

Thanks for your quick response!


With current configs I have unexpected behavior when multicast received 
via unneeded vlan300 not blocked by rule 9000 and bad traffic bridged 
into all bridge members.

So if when net.link.bridge.pfil_member=1 then I can check incoming and 
outgoing bridge members as expected?  I'll try it later, thanks


Is it possible the following config with net.link.bridge.pfil_member=1 ?

table allow239 create type iface
table allow239 add vlan400
3000 allow ip from any to 239.0.0.10 recv vlan100 xmit table(allow239)


It's still very interesting to know full packet path via all interfaces 
(phy, vlan, bridge) and understand where/why ipfw triggered.

For example why i need "allow via igb0"? It's because net.link.ether.ipfw=1?

Can you explain it in details?


Thanks again!


--
CU
Victor Gamov



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49c4193a-d38c-eff8-3ab8-25b103c2dcba>