ipfw on bridge connecting vlans

[Victor Gamov]

On 27/10/2018 21:02, Eugene Grosbein wrote:
> 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;

yes it enabled.

Thanks Eugene!


-- 
CU,
Victor Gamov