From owner-freebsd-net@freebsd.org Wed Aug 28 15:49:00 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 6D5CCDFDF8 for ; Wed, 28 Aug 2019 15:49:00 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 46JVXW2pqMz4M43 for ; Wed, 28 Aug 2019 15:48:59 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id x7SFmoQD076095 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Aug 2019 15:48:53 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: vit@otcnet.ru Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id x7SFmjJh027872 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 28 Aug 2019 22:48:45 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: finding optimal ipfw strategy To: Victor Gamov , freebsd-net@freebsd.org References: <4ff39c8f-341c-5d72-1b26-6558c57bff8d@grosbein.net> <568ed3e1-caec-3988-16a5-0feea80f1630@grosbein.net> <56f81118-a584-01b4-238f-57f9d52a0fc6@otcnet.ru> From: Eugene Grosbein Message-ID: <2751a318-c26b-a14d-0a18-bbd810849606@grosbein.net> Date: Wed, 28 Aug 2019 22:48:37 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <56f81118-a584-01b4-238f-57f9d52a0fc6@otcnet.ru> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 46JVXW2pqMz4M43 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-4.61 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.98)[-0.982,0]; IP_SCORE(-1.53)[ip: (-3.88), ipnet: 2a01:4f8::/29(-1.97), asn: 24940(-1.80), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] 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 15:49:00 -0000 28.08.2019 17:18, Victor Gamov wrote: >> 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? Yes. So, you really do not want any kind of unicast bridging at all and use bridge as "poor man's" replacement for inter-vlan multicast routing, right? In such case you could benefit from small patch that allows you to block ARP packets unconditionally as if they were filtered by ipfw without really passing them through the ruleset. Use sysctl net.link.bridge.ipfw_arp=-1 with the patch (untested): --- if_bridge.c.orig 2019-04-19 17:20:09.724804000 +0700 +++ if_bridge.c 2019-08-28 22:35:14.788891000 +0700 @@ -3153,6 +3153,10 @@ bridge_pfil(struct mbuf **mp, struct ifn switch (ether_type) { case ETHERTYPE_ARP: case ETHERTYPE_REVARP: + if (V_pfil_ipfw_arp == -1) { + error = 0; + goto bad; /* Automatically drop */ + } if (V_pfil_ipfw_arp == 0) return (0); /* Automatically pass */ break; >> 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? Yes. And anything decreasing number of traffic passes over entire ipfw ruleset is efficient.