From nobody Tue Mar 25 11:43:40 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 4ZMSjr37RLz5r9x2 for ; Tue, 25 Mar 2025 11:43:44 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fhigh-a2-smtp.messagingengine.com (fhigh-a2-smtp.messagingengine.com [103.168.172.153]) (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 4ZMSjq2MZpz4Nwm for ; Tue, 25 Mar 2025 11:43:43 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm2 header.b=MYQMHCGN; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=ofTPLkQH; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 103.168.172.153 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 B140211402A4 for ; Tue, 25 Mar 2025 07:43:42 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-10.internal (MEProxy); Tue, 25 Mar 2025 07:43:42 -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 :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1742903022; x=1742989422; bh=2+aGGZihDM Swu65iwsxfUyY+7SApiIPIeYgVDv9y2Do=; b=MYQMHCGNT7Zf2PiaxcyBWJ/rgU rel0DOzmIb7RW7l0wr8t+zL982vLL6Jd62TDut/SXOw9RfQ6ZOwWUOjrUKe9qp8e 7414Nwqv8hYq7Zz3vLEzM2ZzuxqrLfxZmi6mt00XzE9Kt4/iXYUFInIqSsiEHz5C VJiIN6bzJ9s56aURANUAuN15dw90jpt4p+Chsdmv7fZllnXYezgkibrxvNMY+Lne VbO1DrvglFgcCT4DARB2qlq/tRclszbxHe5UPSsojU+ur+IC0ApCnG02m8+KfFGa kQd+Usf/CHPENSUZd+tt4BUzPnc47EgO5jR4rMGqMQz2ZqZaGe75sjANPKkQ== 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:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1742903022; x=1742989422; bh=2+aGGZihDMSwu65iwsxfUyY+7SApiIPIeYg VDv9y2Do=; b=ofTPLkQHxqPrAQOT3Yv6g0SybuBPHhZ8qz0vitQ0Fhz8Fp2JpWW XmPqqgnGRJbn7xhMc4zI3FmdlMpU7YuK9XlCg7RA9o4GfWTFMxTWM83XPrk7419u csCzW+nlRkSKsy//Idt73oANtE4iiiqw+wBJ7eCNk3lSnMCy3Jj8l9B983FQ1i2F 9RFV0E211JG8dxy0TUa7upUtIBFPzYFVeNe9iwehRBhOH9OBBOYnJEVrO/fgYV6w dn3HbxPGZJrhJ6u2rbCriFDd2hSZjLgH2SulJfpBT/aJVLP/9qTxIgPbVcSb0Upe rAPRC+ZF8q3kXgS1zs4tN+U/gXES88w/dTg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdduiedvheeiucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpeffhf fvuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehf qdhmrdhfmheqnecuggftrfgrthhtvghrnhepkeeluddvlefhieelfefggffhffektdehle elgfdugfdvgeekjeejuddtheehgfeunecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomhepvhhoihgusehfqdhmrdhfmhdpnhgspghrtghpthhtohepud dpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepfhhrvggvsghsugdqnhgvthesfhhr vggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 25 Mar 2025 07:43:42 -0400 (EDT) Date: Tue, 25 Mar 2025 11:43:40 +0000 From: void To: freebsd-net@freebsd.org Subject: Re: ipfw layer2+3 firewalling question Message-ID: References: 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 In-Reply-To: X-Spamd-Result: default: False [-0.02 / 15.00]; NEURAL_SPAM_MEDIUM(0.99)[0.990]; NEURAL_HAM_SHORT(-0.98)[-0.978]; NEURAL_SPAM_LONG(0.97)[0.967]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; RWL_MAILSPIKE_EXCELLENT(-0.40)[103.168.172.153:from]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2]; R_SPF_ALLOW(-0.20)[+ip4:103.168.172.128/27]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[103.168.172.153:from]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_FROM(0.00)[f-m.fm]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:209242, ipnet:103.168.172.0/24, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_LAST(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+] X-Rspamd-Queue-Id: 4ZMSjq2MZpz4Nwm X-Spamd-Bar: / Hi Ronald, thank you for your reply. On Sun, Mar 23, 2025 at 08:21:21PM +0100, Ronald Klop wrote: > >I assume that in your setup igb0 is the host interface as well as bridge member. That's correct. >That makes the setup a bit hard to reason about. IMHO you now have a virtual setup >which you wouldn't be able to replace with physical hardware. To mimic a physical >setup you could add another epair interface to act as the host interface and >leave igb0 as a bridge member only. that's something I've not considered > >igb0 ---+--- tap0 -- vmnet > | > +--- tap1 -- vmnet > | > +-- epair0a -- epair0b (this is where the host should listen on) > >And instead of putting the host IP address on igb0 you should put this >on epair0b. > >By default the ipfw firewall will then see the IP traffic of epair0b. As all >the other interfaces only pass ethernet traffic around. > >Something like this in /etc/rc.conf should do the trick. > >cloned_interfaces="bridge0 epair0 tap0 tap1" >ifconfig_bridge0="addm igb0 addm epair0a addm tap0 addm tap1" >ifconfig_igb0="up" >ifconfig_epair0a="up" >ifconfig_epair0b="SYNCDHCP" # or some other inet config ok I'll try that. What I have tried, just for interest, in pf.conf (I know pf is unsuitable, but for an experiment), in /etc/rc.conf, there is cloned_interfaces="bridge0 tap0 tap1" ifconfig_bridge0="addm igb0 addm tap0 tap1" in /etc/pf.conf, there's int_if="igb0" ext_if="igb1" int_taps="{ tap0, tap1 }" >snip< set skip on lo0 set skip on $int_taps set block-policy drop >snip< this gets weird effects like the vm on tap0 cant ping tap1 and so on. I was wondering if something like "set skip on mac_address would work" in the ipfw context, and what its syntax was for specific layer2 filtering. --