From owner-freebsd-net@freebsd.org Sat Oct 27 18:09:46 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D29FB10CF34C for ; Sat, 27 Oct 2018 18:09:45 +0000 (UTC) (envelope-from vit@otcnet.ru) Received: from mail.otcnet.ru (mail.otcnet.ru [194.190.78.3]) by mx1.freebsd.org (Postfix) with ESMTP id 406E07577C for ; Sat, 27 Oct 2018 18:09:45 +0000 (UTC) (envelope-from vit@otcnet.ru) Received: from Victors-MacBook-Air-2.local (unknown [195.91.148.145]) by mail.otcnet.ru (Postfix) with ESMTPSA id 8DCD55967CC for ; Sat, 27 Oct 2018 21:09:44 +0300 (MSK) Subject: Re: ipfw on bridge connecting vlans To: freebsd-net@freebsd.org References: <36cd661e-ca54-be94-fd64-01ee768d5053@otcnet.ru> <9b8d8c04-8e3e-b148-8a08-135d6ac1785d@grosbein.net> <49c4193a-d38c-eff8-3ab8-25b103c2dcba@otcnet.ru> <45f4881e-3a02-5a37-1e77-45b530460fad@grosbein.net> <64d0ceec-2d0c-9086-04e9-72a5f4f678c2@otcnet.ru> From: Victor Gamov Organization: OTCnet Message-ID: <9326bc98-ec90-b68f-f08d-b2f021bb2f90@otcnet.ru> Date: Sat, 27 Oct 2018 21:09:46 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2018 18:09:46 -0000 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