From nobody Thu Sep 11 07:35:13 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 4cMq8k6822z62ZNF for ; Thu, 11 Sep 2025 07:35:18 +0000 (UTC) (envelope-from ml@netfence.it) Received: from soth.netfence.it (mailserver.netfence.it [78.134.96.152]) (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 (2048 bits) client-digest SHA256) (Client CN "mailserver.netfence.it", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cMq8j6gVgz4Dsn for ; Thu, 11 Sep 2025 07:35:17 +0000 (UTC) (envelope-from ml@netfence.it) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=netfence.it; spf=pass (mx1.freebsd.org: domain of ml@netfence.it designates 78.134.96.152 as permitted sender) smtp.mailfrom=ml@netfence.it Received: from [10.1.2.18] (alamar.local.netfence.it [10.1.2.18]) (authenticated bits=0) by soth.netfence.it (8.18.1/8.17.2) with ESMTPSA id 58B7ZD98012395 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Thu, 11 Sep 2025 09:35:14 +0200 (CEST) (envelope-from ml@netfence.it) X-Authentication-Warning: soth.netfence.it: Host alamar.local.netfence.it [10.1.2.18] claimed to be [10.1.2.18] Message-ID: Date: Thu, 11 Sep 2025 09:35:13 +0200 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: Help with bridge and new IP requirements Content-Language: en-US To: freebsd-net@freebsd.org References: <24b8c39e-b1a3-4cd3-accc-c86a03e21689@netfence.it> From: Andrea Venturoli In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: - X-Spamd-Result: default: False [-1.84 / 15.00]; NEURAL_HAM_LONG(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[netfence.it,none]; NEURAL_HAM_SHORT(-0.42)[-0.421]; NEURAL_SPAM_MEDIUM(0.38)[0.379]; R_SPF_ALLOW(-0.20)[+ip4:78.134.96.152]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:35612, ipnet:78.134.0.0/17, country:IT]; RCVD_COUNT_ONE(0.00)[1]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; FROM_HAS_DN(0.00)[]; HAS_XAW(0.00)[]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4cMq8j6gVgz4Dsn On 9/10/25 20:56, Lexi Winter wrote: > this seems correct to me. Thanks. >> I have: >>> # sysctl -a|grep -E "bridge.*(pfil|ipfw)" >>> net.link.bridge.ipfw: 0 >>> net.link.bridge.pfil_local_phys: 1 >>> net.link.bridge.pfil_member: 1 >>> net.link.bridge.ipfw_arp: 0 >>> net.link.bridge.pfil_bridge: 0 >>> net.link.bridge.pfil_onlyip: 1 >> >> So I'd excpect I would need to use rules on the member interfaces (e.g. >> vlan1), as I've always done. >> Yet I see packets are being blocked on bridge0. E.g.: >>> kernel: ipfw: 1997 Deny ICMP:8.0 192.168.1.18 192.168.1.15 in via bridge0 > > what exactly are you trying to achieve here? I have: _ "base" system; _ connected to LAN and Internet; _ running some (non VNET) jails; _ and some Bhyve VMs. What I currently do is firewalling traffic from/to: _ host <-> Internet; _ host <-> jails; _ jails <-> jails; _ jails -> Internet; _ VMs -> jails; _ VMs -> Internet; _ LAN clients <-> host; _ LAN clients -> Internet; _ LAN clients -> jails; _ LAN clients -> VMs. I expect I should be able to do that with the new configuration. > with the new configuration, from pfil's perspective, packets for VLAN 1 > should be seen as arriving on the "bridge0" interface. Hmmm... IF_BRIDGE(4) says: > ... When filtering is enabled, bridged packets will > pass through the filter inbound on the originating interface, on the > bridge interface and outbound on the appropriate interfaces. Either > stage can be disabled. The filtering behavior can be controlled using > sysctl(8): > ... > net.link.bridge.pfil_member > Set to 1 to enable filtering on the incoming and outgoing member > interfaces, set to 0 to disable it. So, setting net.link.bridge.pfil_member=1, I was always able to filter on vlan1 or tap0, i.e. distinguish which packets came from external clients vs local VMs. Are you confirming that, by moving the IP to the bridge0 interface, this is not possible anymore? > so, if you want > to filter what the host can send and receive on this VLAN, simply use > the "bridge0" interface in your filters. I'll have to investigate this... I guess this is possible, but more complicated. Let's say I have 192.168.1.0/24 net on bridg0/vlan1/tap0, with 192.168.1.1 host 192.168.1.5 VM Before I could do, e.g.: allow tcp from any to me 1000 in via vlan1 allow tcp from any to me 2000 in via tap0 Now I would probably need something like: deny tcp from 192.168.1.5 to me 1000 allow tcp from any to me 1000 in via bridge0 allow tcp from any to me 2000 in via bridge0 Anyway I'll try and see. > then, you should set net.link.bridge.pfil_local_phys=0 because you are > only filtering layer 3 traffic. I don't follow here, sorry. Isn't this needed in order to isolate the VMs and prevent them free access to the whole base host? > if you are trying to do layer 2 filtering (i.e., you want to filter what > bridge ports can send to each other) then this is more complicated and, > to be honest, i don't use L2 filtering so i'm not an expert on how this > should work, but if you can describe the desired outcome, someone might > be able to suggest something. I used layer 2 filtering in the past, but it was some 20 years ago; I don't remember well how I did it. I'd like to avoid it if possible, but will resort to it, if it's the only way to achieve the above (unless there are simpler solutions I'm not aware of). I'm just a bit suprised: before this required change, I was doing everything without L2 filtering... bye & Thanks av.