Date: Thu, 11 Sep 2025 09:35:13 +0200 From: Andrea Venturoli <ml@netfence.it> To: freebsd-net@freebsd.org Subject: Re: Help with bridge and new IP requirements Message-ID: <a6cc314a-d742-4af4-9176-0ef1348fe0ad@netfence.it> In-Reply-To: <aMHJxF__hASEVQfe@amaryllis.le-fay.org> References: <24b8c39e-b1a3-4cd3-accc-c86a03e21689@netfence.it> <aMHJxF__hASEVQfe@amaryllis.le-fay.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a6cc314a-d742-4af4-9176-0ef1348fe0ad>