ipfw on bridge connecting vlans

[Eugene Grosbein]

28.10.2018 0:48, Victor Gamov wrote:

> On 27/10/2018 19:33, Eugene Grosbein wrote:
>> 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 (*).
> 
> ok, frame path and ipfw as I see it.
> 
> =====
> 1000 allow ip from any to any via igb0
> 1002 allow ip from any to any via igb2
> 
> 1100 deny ip from any to any mac-type 0x0806 via bridge2
> 1102 allow ip from any to any via bridge2
> 
> 2000 allow ip from any to 239.0.0.10 in recv vlan200
> 
> 4000 allow ip from any to 239.0.0.10 out xmit table(allow239)
> 
> 9000 deny ip from any to any via table(block239)
> 
> 65000 allow ip from any to any
> =====
> 
> 1. tagged frame come to physical interface igb0.
> As I have net.link.ether.ipfw=1 then tagged frame checked by IPFW and I need
> 1000 allow ip from any to any via igb0
> 
> Frame passed via igb0 and untagged.
> 
> 
> 2. untagged frame appears on vlan100.
> Now I can get it via `tcpdump -i vlan100`
> 
> Frame checked by IPFW on vlan100 because
> net.link.bridge.pfil_member=1 AND vlan100 is a bridge member
> ( net.link.ether.ipfw=1 is irrelevant? )
> 
> So I can pass/block traffic here.
> 2000 allow ip from any to 239.0.0.10 in recv vlan100
> 9000 block ip from any to any via table(block239)
> Frame accepted on VLAN-100
> 
> 
> 3. frame (untagged but still ethernet frame not IP packet) appears on bridge2 as incoming and checked by IPFW due net.link.bridge.ipfw=1.
> 
> I block ARP but allow all other frames (1100 + 1102)
> 
> 
> 4. frame appears on all bridge-member vlans.
> Frame checked by IPFW on vlan300/vlan400 because
> net.link.bridge.pfil_member=1 AND vlan300/vlan400 is a bridge member
> 
> So I can pass/block traffic here.
> 4000 allow ip from any to 239.0.0.10 out xmit table(allow239)
> 9000 block ip from any to any via table(block239)
> 
> Passed frames tagged
> 
> 
> 5. tagged frame appears on igb2
> As I have net.link.ether.ipfw=1 then tagged frame checked by IPFW and I need
> 1002 allow ip from any to any via igb2
> 
> 
> Is this scheme is correct?
> 
> 

Almost right with one exception: bridge considers ARP (and REVARP) packets special
and passed them through the ruleset only when sysctl net.link.bridge.ipfw_arp=1;