ipfw on bridge connecting vlans

[Eugene Grosbein]

27.10.2018 23:26, Victor Gamov wrote:

[skip]

>> 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.

(*)

> 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 ?

Yes, it should be.
 
> table allow239 create type iface
> table allow239 add vlan400
> 3000 allow ip from any to 239.0.0.10 recv vlan100 xmit table(allow239)

You also should add the "out" keyword to this rule for performance and clearness
because only outgoing frames have "xmit" attribute to check, so this rule is not tried
for incoming frames (it won't match them anyway).

> 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?

See above (*).