From nobody Sun Mar 23 19:21:21 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 4ZLQys1rDvz5rhsr for ; Sun, 23 Mar 2025 19:21:25 +0000 (UTC) (envelope-from ronald@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZLQys0rjqz3ThG; Sun, 23 Mar 2025 19:21:25 +0000 (UTC) (envelope-from ronald@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1742757685; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=r9elAAjEoeCkTOkaufIyJ0XIVnH0Yp6eREXaXDfR6+M=; b=tzNa22TsKtvtWFLpmjz/cioAguOxrFStTPjaD60MHjIEoOSFJK5cxfI/MQxfRgxDbTiLo4 +m/5pd+un0pmSko+oRTlZLQVHLDGusEJXtHe650j3KctLjwt/tPeCwDusc1EeIqgr4Bxdi yMi1r8ZzNOk9AzGDlkMC35phDQcumJXyHA1JdHZPEs1PVGK63lIlRXnTpQXTUFwcsSV3ao ro8B0cImm/eOJKFIgwlRo5m1rOWqQXZ1xGtWqKbtKxfHAGrgnxp9dpLRMPBColsQQWq25q /xFNay1FoClNVOPM1Ri93LADwXRzPHTIQ5Z/Gh+Grsxb+8+5IGrGYOPbQW1MYw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1742757685; a=rsa-sha256; cv=none; b=GcXJX2KpHbWqI7q48/FzS4cEcYcVcajU39V/eUyKRGymHeRLyw+4AI3UXa/VMuVkTM4Yyw bf7qY83BIz2OcCgvfQnAX11tfLJfXgYnKGFDuFQrXUnvxCWp2SKE7u7TMU7svkZeMuedk8 k4rjBH73Gtc7P3Om7D3S/bqoHF9xXB3WgI9AAfLO7gF/mqdhLKP7ujVlUYpWp97xs9/nqW yjImSDn98HxSiuXp8vDYQ0jQPoM0N6ENoQRxyeGq1z/OmXQ904TZWpyY2F8+ZYWW5Z2STU p/fSKmMIrMulup3EJke9m3//1xgZTJqVEMuFx31lr8wQL2hRE7xHZeRjejDQ1w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1742757685; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=r9elAAjEoeCkTOkaufIyJ0XIVnH0Yp6eREXaXDfR6+M=; b=uimmzI+Wv0ppQPMRzHjAWKY6ZEAKrCoswUWjdFZtugYFr/cnLjT2t3R9hTbFSF7s0OMpcj hGrblQMaDiuBiP93eqhX2FTllQf3KoRZoDsy01s9LMlLrUu8sZMpgV5PGI3jRppUCmXyuG 6WZlEvvxywrwoG9UBiJpvFF4HweEN5Vrb3tcpuB5PBncmw/+aVnJnQ7Wes2SOFJtymZ2h8 5UswnACO5eG9rDrR9ZKAR7x5AEFHjeGn8XU+YpRwE7JsSmmL/AVfpk6SSprDMIrejEGWrv f8bOIjHxr0z+hOeaFwUAhD9Daw2S8vQ5EoodqgzglLpjHS3GWTPwTyOa1ZtVUQ== Received: from [IPV6:2001:1c00:2709:2010:44fb:a015:f4fe:2eb4] (2001-1c00-2709-2010-44fb-a015-f4fe-2eb4.cable.dynamic.v6.ziggo.nl [IPv6:2001:1c00:2709:2010:44fb:a015:f4fe:2eb4]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: ronald/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZLQyr3vf0z10Bf; Sun, 23 Mar 2025 19:21:24 +0000 (UTC) (envelope-from ronald@FreeBSD.org) Message-ID: Date: Sun, 23 Mar 2025 20:21:21 +0100 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 User-Agent: Mozilla Thunderbird Subject: Re: ipfw layer2+3 firewalling question To: void , freebsd-net@freebsd.org References: Content-Language: en-US From: Ronald Klop In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Op 23-03-2025 om 15:07 schreef void: > 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? I assume that in your setup igb0 is the host interface as well as bridge member. 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. 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 NB: this https://wiki.freebsd.org/SummerOfCodeIdeas#Implement_a_new_VLAN_filtering_software_bridge also explains about the problem of having members with configured IP addresses in bridges. I might have misinterpreted your question. If so please provide more details of your setup. Regards, Ronald.