From owner-freebsd-net@freebsd.org Thu Aug 29 19:02:01 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 E95BADD9E5 for ; Thu, 29 Aug 2019 19:02:01 +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 46KBmm6PP3z44ZQ for ; Thu, 29 Aug 2019 19:02:00 +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 x7TJ1rrK009221 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 29 Aug 2019 19:01:55 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: freebsd-rwg@gndrsh.dnsmgr.net Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id x7TJ1nss044696 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 30 Aug 2019 02:01:49 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: finding optimal ipfw strategy To: "Rodney W. Grimes" References: <201908291839.x7TIdlmh091176@gndrsh.dnsmgr.net> Cc: freebsd-net@freebsd.org, Victor Gamov From: Eugene Grosbein Message-ID: <46399afc-89d9-ceea-5144-a6d2f5f102ab@grosbein.net> Date: Fri, 30 Aug 2019 02:01:40 +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: <201908291839.x7TIdlmh091176@gndrsh.dnsmgr.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: 46KBmm6PP3z44ZQ 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.65 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; 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)[]; NEURAL_HAM_SHORT(-0.98)[-0.980,0]; IP_SCORE(-1.57)[ip: (-4.08), 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: Thu, 29 Aug 2019 19:02:02 -0000 30.08.2019 1:39, Rodney W. Grimes wrote: > One of the things I do when writting a firewall is very early break > up the traffic based on which interface(s) it is coming in/out of > and do a skipto based on that, then further classify based on layers > so that I am usually only doing 1 compare as it traverse down what > is in effect a trie. > > dispatch on interface(s) > dispatch on protocol (IP, ESP, OSPF, IGMP, ICMP, etc) > IP: dispatch on transport (TCP, UDP, SCTP...) > IPTCP: dispatch on setup, established.. > IPTCPsetup: dispatch on ports > IPUDP: ... > > I try to write my sets so that I never do the same comparison on > a packet at any point in the firewall. Ie, once your in the IPTCP > set of rules I no longer check for tcp, only check port numbers > and flags (setup, established, etc) > > Does this seem like a reasonable and efficient approach? Correct but that's important for high-load scenario only and when firewall processing constitutes most or significant part of work performed by the box. If userland work's much heavier, this could be unimportant complication :-) >>> I hope I can place such rule at top of ruleset and only allowed multicast packets outgoing via VLANs interfaces will hit this rule. >>> and second: >>> allow udp from $src1 to { 239.1.2.55 or 239.1.2.56 } >>> or >>> allow udp from src1 to 239.1.2.0/24{55,56} >> Last one should me much more efficient as it just needs to perform a couple of 32-bit masking operations >> and previous one is more general (IP addresses may belong to different networks) and requires slower search. > I disagree, the first one should be 2 simple 32 bit compares, > the second one is a 32 bit AND (mask), and then 2 8 bit compares, > and actually probably actually 32 bit compares due to data type promotion. That's an example only and I've answered considering scaled picture where there are many more IPs to check for.