From owner-freebsd-net@freebsd.org Sat Oct 27 16:26:42 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 2C0DC10C9DD5 for ; Sat, 27 Oct 2018 16:26:42 +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 BDB7870818 for ; Sat, 27 Oct 2018 16:26:41 +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 A99315965A3 for ; Sat, 27 Oct 2018 19:26:40 +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> From: Victor Gamov Organization: OTCnet Message-ID: <49c4193a-d38c-eff8-3ab8-25b103c2dcba@otcnet.ru> Date: Sat, 27 Oct 2018 19:26:41 +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: <9b8d8c04-8e3e-b148-8a08-135d6ac1785d@grosbein.net> 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 16:26:42 -0000 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