From owner-freebsd-net@freebsd.org Wed Aug 28 10:18:49 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 020B7D84A9 for ; Wed, 28 Aug 2019 10:18:49 +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 46JMCW5lrzz42Y9 for ; Wed, 28 Aug 2019 10:18:47 +0000 (UTC) (envelope-from vit@otcnet.ru) Received: from Victors-MacBook-Air-2.local (unknown [188.164.215.2]) by mail.otcnet.ru (Postfix) with ESMTPSA id 9C00B5CD20; Wed, 28 Aug 2019 13:18:44 +0300 (MSK) Subject: Re: finding optimal ipfw strategy To: Eugene Grosbein , "Andrey V. Elsukov" , freebsd-net@freebsd.org References: <4ff39c8f-341c-5d72-1b26-6558c57bff8d@grosbein.net> <568ed3e1-caec-3988-16a5-0feea80f1630@grosbein.net> From: Victor Gamov Organization: OTCnet Message-ID: <56f81118-a584-01b4-238f-57f9d52a0fc6@otcnet.ru> Date: Wed, 28 Aug 2019 13:18:43 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <568ed3e1-caec-3988-16a5-0feea80f1630@grosbein.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46JMCW5lrzz42Y9 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of vit@otcnet.ru designates 194.190.78.3 as permitted sender) smtp.mailfrom=vit@otcnet.ru X-Spamd-Result: default: False [-6.51 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+a:mail.otcnet.ru]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[otcnet.ru]; TO_DN_SOME(0.00)[]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.985,0]; IP_SCORE(-3.33)[ip: (-8.76), ipnet: 194.190.78.0/24(-4.38), asn: 50822(-3.50), country: RU(0.01)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:50822, ipnet:194.190.78.0/24, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] 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: Wed, 28 Aug 2019 10:18:49 -0000 On 28/08/2019 24:45, Eugene Grosbein wrote: > 28.08.2019 3:59, Victor Gamov wrote: > >>>> sysctl.conf ===== net.link.ether.ipfw=1 net.link.bridge.ipfw=1 >>>> net.link.bridge.ipfw_arp=1 net.link.bridge.pfil_member=1 >>>> >>>> net.inet.ip.fw.verbose_limit=100 net.inet.ip.fw.verbose=1 >>>> ===== > >>> Do you really use ipfw filtering based on layer2 parameters like >>> MAC addresses? If not, you should disable net.link.ether.ipfw. If >>> yes, you should use "layer2" keyword explicily in rules filtering >>> by ethernet headers and place these rules above others and use >>> "allow ip from any to any layer2" after L2 filtering is done, so >>> L2 packets do not go through other rules extra time. >>> >>> Do you really need to filter each bridged L3 packet twice? Once >>> as "out xmit $bridge" and once as "out xmit $brige_member"? If >>> not, you should disable net.link.bridge.ipfw and keep >>> net.link.bridge.pfil_member=1 only. >> >> Packets must be filtered on input VLANs (bridge members) and on >> output VLANs. So net.link.bridge.pfil_member=1 >>> Perhaps, you are ruining the performance with such settings >>> making same work 3 times without real need. Do you really need >>> filtering ARP? Disable net.link.bridge.ipfw_arp if not. >> I need to drop ARP moving via bridge. As I use many VLANs all VLAN >> must be isolated and only multicast must be bridged from one VLAN >> to others. To block ARP following rule used: deny ip from any to >> any mac-type 0x0806 via bridge1202 As I understand correctly I need >> net.link.bridge.ipfw_arp and net.link.bridge.ipfw to do it. I'm >> not sure about net.link.ether.ipfw > > Why do you need to filter ARP on bridge? That's unusial. VLANs are > isolated by default and by definition, unless you explicitly enable > inter-vlan routing and setup your routing table. May be I have some misunderstood here but... If I have many VLANs bridged via bridge interface then ARP received from one VLAN will be send to all bridge members. So it will be send to all unwanted VLANs. Is it correct? > Anyway, you can skip entire ipfw pass over a bridge because you > filter its members anyway, so just drop ARP coming from any vlan with > exception of controlling one: > > allow ip from any to any layer2 mac-type 0x0806 in recv $controlvlan > deny ip from any to any layer2 mac-type 0x0806 in allow ip from any > to any layer2 > > And then disable filtering for bridge itself altogether. Decreasing > number of passes over ipfw should be your top priority because that's > what can provide you with most benefit. You should even rewrite your > ruleset if that is needed to achieve this goal. If I set net.link.bridge.ipfw=0 but net.link.ether.ipfw and net.link.bridge.ipfw still set to 1 is it still possible block unwanted ARP received from one VLAN and bridged to other on outgoing VLAN like deny ip from any to any layer2 mac-type 0x0806 out xmit MAC not $mymac any Is it correct and more effective than net.link.bridge.ipfw=1 if I have "deny mac-type 0x0806 via bridge" at rules top? -- CU, Victor Gamov