From nobody Sun Mar 23 14:07:53 2025 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZLJ195zq0z5rLsV for ; Sun, 23 Mar 2025 14:07:57 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fhigh-a6-smtp.messagingengine.com (fhigh-a6-smtp.messagingengine.com [103.168.172.157]) (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) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZLJ1850kwz3b8m for ; Sun, 23 Mar 2025 14:07:56 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm1 header.b="b5y6Bs/D"; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="U a5nnWk"; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 103.168.172.157 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from phl-compute-10.internal (phl-compute-10.phl.internal [10.202.2.50]) by mailfhigh.phl.internal (Postfix) with ESMTP id 6CB561140151 for ; Sun, 23 Mar 2025 10:07:55 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-10.internal (MEProxy); Sun, 23 Mar 2025 10:07:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:subject:subject:to:to; s=fm1; t=1742738875; x=1742825275; bh=8D/DqBGG5hpo3VmWpDug/b/9Mm4mRra5 f4B5z1uzYG0=; b=b5y6Bs/DkyNrfluV6HgU2aTAaT1ikpUrCjidD9Opd/2sPf4r ypJBYFyUfG+iTcASCffl3RKlxWjpMLg/wWbjT3Uoiob4CXQXxPMMZCJzlyUL39XA vPytOuwVe3Viaoays4UghoqzxP+Qmea3msyXYOBwNB+8vBUc548pTtS4xsXZWoq4 GyswpFBEHSGh9dogKGR7uGjpal1HuTCB/4mtRz9vN8KeSQnrvUJTFDx2NkqoCDau 165lxFwu7mAeVjN6uXSCzrcI5peDAxgSJyFLmtOj80g9rpOw7smnYbeeJxT6i5PX Urao+CMYR02zy85aDzTEBm/sld5ByYpbS9VPIg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1742738875; x= 1742825275; bh=8D/DqBGG5hpo3VmWpDug/b/9Mm4mRra5f4B5z1uzYG0=; b=U a5nnWkeh3u+rLA/ulOcFXR4yhDYLqTOej8fKd3b36ubEHyZ2Smzjy/DTdZmmfJFO d9YczPDfghq7PlM232nLIWzteV9fNs5qCgv0mKUaQKgz9nNM4XuVDgsuesnfdRzh V4e8pvCX6NUyIQmIrJkEM2FeuQEIJSXV83O1A41ro6OhytI5y3YlAOwWon+7VTn5 fiInhkZJyT5FYq46ARhAiyCCM3MFiHnmefLhykQBNdtiU3U/lkJYyjHgVe7QjVIt 8ZKJVarZitTRQY3s2pXQA23Fm20GGR0Tp3sc4RIHT/Qt7/8yMxsxcUc2JuCiNxXF tknuFCw1KR5Z8PDQQCyNQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdduheejtdejucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpeffhf fvuffkgggtugesthdtredttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhm rdhfmheqnecuggftrfgrthhtvghrnhepveduffeivdfffffghfegfeejfefftdeiteehte ekfefhvdefgfettdeuheegffeunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghm pehmrghilhhfrhhomhepvhhoihgusehfqdhmrdhfmhdpnhgspghrtghpthhtohepuddpmh houggvpehsmhhtphhouhhtpdhrtghpthhtohepfhhrvggvsghsugdqnhgvthesfhhrvggv sghsugdrohhrgh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 23 Mar 2025 10:07:54 -0400 (EDT) Date: Sun, 23 Mar 2025 14:07:53 +0000 From: void To: freebsd-net@freebsd.org Subject: ipfw layer2+3 firewalling question Message-ID: List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline X-Spamd-Result: default: False [-0.95 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[103.168.172.157:from]; NEURAL_HAM_SHORT(-0.99)[-0.994]; NEURAL_SPAM_LONG(0.92)[0.922]; NEURAL_SPAM_MEDIUM(0.73)[0.725]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm1,messagingengine.com:s=fm1]; R_SPF_ALLOW(-0.20)[+ip4:103.168.172.128/27]; RCVD_IN_DNSWL_LOW(-0.10)[103.168.172.157:from]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; FREEMAIL_FROM(0.00)[f-m.fm]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; ASN(0.00)[asn:209242, ipnet:103.168.172.0/24, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4ZLJ1850kwz3b8m X-Spamd-Bar: / Hi, (originally posted on the forums) My objective is to protect services on a bhyve host, while allowing traffic to the bhyve guests to pass to and from them unprocessed, as these each have pf and their own firewall policies. The host running recent -current. I know ipfw can process both layer 2 and layer 3 traffic, but pf only processes layer 3, and to filter on bridge or tap requires layer2, so that is why i want to use ipfw on the bhyve host. So we have bridge0 with igb0 tap0 and tap1 as members. In this example, igb0 has a mac address of 11:11:11:11:11:11 tap0 has 22:22:22:22:22:22 tap1 has 33:33:33:33:33:33 How can I tell ipfw to pass 22:22:22:22:22:22 and 33:33:33:33:33:33 and apply no more rules to frames matching those MACs? Let's say I want to just block on 11:11:11:11:11:11 (igb0) port 22 apart from 10.0.0.0/24, and define that rule with the regular layer3 syntax. and then want 22:22:22:22:22:22 passing unhindered, unprocessed. Possible? Looking for a worked example but can't seem to find one Could it be like "$cmd add allow all from any to any via tap0" or "$cmd add allow all from any to any via 22:22:22:22:22:22" or something else? There are a number of ipfw sysctls. Like net.link.bridge.ipfw net.link.bridge.allow_llz_overlap net.link.bridge.pfil_local_phys net.link.bridge.pfil_member net.link.bridge.ipfw_arp net.link.bridge.pfil_bridge net.link.bridge.pfil_onlyip Are any of these needed in my context? I need to allow based on tap, not the bridge (I guess). The bridge has the real interface (igb0) as a member as well. So I think that would preclude me from using the above sysctls. Is this correct? --