From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id F00B2158091 for ; Fri, 17 Jun 2022 04:48:04 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 746E4E0916; Fri, 17 Jun 2022 04:47:57 +0000 (UTC) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C1D03E08FB for ; Fri, 17 Jun 2022 04:47:56 +0000 (UTC) Received: by mail-ej1-x634.google.com with SMTP id h23so6499588ejj.12 for ; Thu, 16 Jun 2022 21:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:subject:from:to:date:in-reply-to:references :content-transfer-encoding:user-agent:mime-version; bh=9Dc4g4cL7DtRKX01mpaTaCUIDmSfp3sgs/R9cNHhvqs=; b=GoMrRDMOhFrg5SKxH5eE4AnY6Iq5jVtOGHItoX66TswU6JRfOrL25vhw8AflxZOvar briXNcJU1NI9Ax+9E1nHb1xrpPat5stBxBUIG3E0ebto0ZaatKOuRuiVhfb2nqOjPkkt Lsw3VfpT/R86x34xrCE6zUysa1gmIj1BZFl/kXEVQM4yyMjMxV3q1Pq/YnwnFiV2GCvW +jWFYHD1rwg5HVpvKNlNv0DgzJIuNKPuxRfpZ/Kf12nTVr4plaOGu+LpxKrn17D/quB8 1SXt2uhVfMZx+G9RhC2TRYX8Ob/K3HQUCPVE0KGchbFMHhkk3AsT8OeDRb4/WmNbJ9Tn 3B6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:content-transfer-encoding:user-agent:mime-version; bh=9Dc4g4cL7DtRKX01mpaTaCUIDmSfp3sgs/R9cNHhvqs=; b=kzm+P7mVafgt08iUr9NJ65SqRrwXs8PaL40GRzX6oIbXODej6fTkzKwJSInDtTG6S1 oItPNIONGOPQKdSh0yBnLmUzBu2Pjn5QxEm0QkGdbP64YyxIp1QKPb+mIF4iL7Su5W4S X9g+2NJ9cOUy5eN0YxE2FjIlP8ibHT5co2xHLwLRxAPXLzsqitOOTdlsFzmD1EbNmnEL sjgNYxYE6Gzn3M486A1K+MeaWiHHyDG+FguMTRdzwPaZklD7T+xaC/p9IRCSiQ+Wggco +mn1RcWZpba8+vec3goabC3O0+wQOhBMH8so2iYWb/VUms/UCNMVgTy+EEYk1rOy48bo QEjg== X-Gm-Message-State: AJIora/1NwO98JNiMoFGpIqfQmBKN/yPnm5jNxPXt23P7gToP0Mf58Ss lNW9/O+pQMhCyTDOLyYH7JQnXTxXwzQ= X-Google-Smtp-Source: AGRyM1vCv5t5hQ75jMGhFiMl7BKdxpruBaCSyaY98xLy8yyt41qjxUEzQOVj6bVHkn9XQee3i3iydQ== X-Received: by 2002:a17:907:8c0c:b0:718:d033:dec5 with SMTP id ta12-20020a1709078c0c00b00718d033dec5mr7426733ejc.744.1655441275481; Thu, 16 Jun 2022 21:47:55 -0700 (PDT) Received: from selina.fzu.cz (selina.fzu.cz. [147.231.26.21]) by smtp.gmail.com with ESMTPSA id cd18-20020a170906b35200b0070a80f03a44sm1625048ejb.119.2022.06.16.21.47.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Jun 2022 21:47:54 -0700 (PDT) Message-ID: Subject: Re: [gentoo-user] netfilter partial MAC filtering From: Samuraiii To: gentoo-user@lists.gentoo.org Date: Fri, 17 Jun 2022 06:47:53 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.2 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 X-Archives-Salt: b6d2f3f9-0299-4964-9c1a-043113760ff6 X-Archives-Hash: b241bdc2c9baabc53aa1a6374343476e On Fri, 2022-06-17 at 01:32 +0000, Laurence Perkins wrote: > I am designing a small system with a switch and an uplink.=C2=A0 It needs > to be able to forward traffic from trusted, and only trusted, devices > connected to the switch out through the uplink. > =C2=A0 > Since all potential trusted devices will have the same MAC OUI prefix > in this case, the immediately obvious course of action would be to > base the decision on that. > =C2=A0 > Unfortunately, there doesn't seem to be a good way to do so.=C2=A0 There > was > https://serverfault.com/questions/877576/shorewall-wildcard-filter- > by-source-mac-address from a few years ago, with the answer being > "You can't." > =C2=A0 > While I didn't bother to test it, I'm guessing that adding about 16 > million MAC filtering rules to the firewall won't be good for > performance.=C2=A0 I briefly thought I could use the string matching or > the U32 filters, but unfortunately it appears that they can't access > anything prior to the start of the IP section, so picking bytes out > of the ethernet header isn't possible. > =C2=A0 > I did find > https://martin.uy/blog/wildcard-support-for-mac-addresses-in-netfilter-li= nux-kernel-and-iptables/ > =C2=A0=C2=A0 But it's old, and has something of a glaring flaw with regar= d to > false wildcard matches. > =C2=A0 > I can think of a few ways to do this, mostly involving somehow > monitoring incoming packets and noting the MAC addresses which have > the correct prefix, and then having a little daemon pick up those > addresses and add rules to let them through. > =C2=A0 > Either that, or try to write a custom netfilter module. > =C2=A0 > None of this seems particularly "fun" to sort out.=C2=A0 Does anybody kno= w > of any common solutions for doing packet matching based on just part > of a MAC address on Linux?=C2=A0 Failing that, some advice about whether > the system daemon and packet inspection route or the netfilter module > route is more likely to be stable and maintainable would be > appreciated. > =C2=A0 > Thanks, > LMP Hi, I would recommend to look into nftables and its set feature... It should perform better with one rule for multiple matches. I bet no one had tried it with 16M items, but it is the best, as far as I know. Cheers S https://wiki.nftables.org/wiki-nftables/index.php/Sets https://developers.redhat.com/blog/2017/04/11/benchmarking-nftables#the_fir= st_test