Date: Thu, 11 Sep 2025 10:47:18 +0200 (CEST) From: Ronald Klop <ronald-lists@klop.ws> To: Andrea Venturoli <ml@netfence.it> Cc: freebsd-net@freebsd.org Subject: Re: Help with bridge and new IP requirements Message-ID: <940777963.3060.1757580438384@localhost> In-Reply-To: <a6cc314a-d742-4af4-9176-0ef1348fe0ad@netfence.it> References: <24b8c39e-b1a3-4cd3-accc-c86a03e21689@netfence.it> <aMHJxF__hASEVQfe@amaryllis.le-fay.org> <a6cc314a-d742-4af4-9176-0ef1348fe0ad@netfence.it>
next in thread | previous in thread | raw e-mail | index | archive | help
------=_Part_3059_1985361024.1757580438370 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, I can do: sysctl net.link.bridge.pfil_member=1 ipfw add 150 deny ip from any to any via epair4a And than my jail which uses epair4b does not get any traffic anymore. I don't have any other bridge settings apart from: net.link.bridge.member_ifaddrs=0 (so no IP address on the bridge members) This is running on 16-CURRENT which is of course still similar to 15 nowadays. Does this help? Regards, Ronald. Van: Andrea Venturoli <ml@netfence.it> Datum: donderdag, 11 september 2025 09:35 Aan: freebsd-net@freebsd.org Onderwerp: Re: Help with bridge and new IP requirements > > 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. > > > > ------=_Part_3059_1985361024.1757580438370 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <html><head></head><body>Hi,<br> <br> I can do:<br> <br> sysctl net.link.bridge.pfil_member=1<br> ipfw add 150 deny ip from any to any via epair4a<br> <br> And than my jail which uses epair4b does not get any traffic anymore.<br> <br> I don't have any other bridge settings apart from:<br> net.link.bridge.member_ifaddrs=0 (so no IP address on the bridge members)<br> <br> This is running on 16-CURRENT which is of course still similar to 15 nowadays.<br> <br> Does this help?<br> <br> Regards,<br> Ronald.<br> <br> <p><strong>Van:</strong> Andrea Venturoli <ml@netfence.it><br> <strong>Datum:</strong> donderdag, 11 september 2025 09:35<br> <strong>Aan:</strong> freebsd-net@freebsd.org<br> <strong>Onderwerp:</strong> Re: Help with bridge and new IP requirements</p> <blockquote style="padding-right: 0px; padding-left: 5px; margin-left: 5px; border-left: #000000 2px solid; margin-right: 0px"> <div class="MessageRFC822Viewer" id="P"> <div class="TextPlainViewer" id="P.P">On 9/10/25 20:56, Lexi Winter wrote:<br> <br> > this seems correct to me.<br> <br> Thanks.<br> <br> <br> <br> <br> <br> >> I have:<br> >>> # sysctl -a|grep -E "bridge.*(pfil|ipfw)"<br> >>> net.link.bridge.ipfw: 0<br> >>> net.link.bridge.pfil_local_phys: 1<br> >>> net.link.bridge.pfil_member: 1<br> >>> net.link.bridge.ipfw_arp: 0<br> >>> net.link.bridge.pfil_bridge: 0<br> >>> net.link.bridge.pfil_onlyip: 1<br> >><br> >> So I'd excpect I would need to use rules on the member interfaces (e.g.<br> >> vlan1), as I've always done.<br> >> Yet I see packets are being blocked on bridge0. E.g.:<br> >>> kernel: ipfw: 1997 Deny ICMP:8.0 192.168.1.18 192.168.1.15 in via bridge0<br> ><br> > what exactly are you trying to achieve here?<br> <br> I have:<br> _ "base" system;<br> _ connected to LAN and Internet;<br> _ running some (non VNET) jails;<br> _ and some Bhyve VMs.<br> <br> What I currently do is firewalling traffic from/to:<br> _ host <-> Internet;<br> _ host <-> jails;<br> _ jails <-> jails;<br> _ jails -> Internet;<br> _ VMs -> jails;<br> _ VMs -> Internet;<br> _ LAN clients <-> host;<br> _ LAN clients -> Internet;<br> _ LAN clients -> jails;<br> _ LAN clients -> VMs.<br> <br> I expect I should be able to do that with the new configuration.<br> <br> <br> <br> <br> <br> > with the new configuration, from pfil's perspective, packets for VLAN 1<br> > should be seen as arriving on the "bridge0" interface.<br> <br> Hmmm...<br> IF_BRIDGE(4) says:<br> > ... When filtering is enabled, bridged packets will<br> > pass through the filter inbound on the originating interface, on the<br> > bridge interface and outbound on the appropriate interfaces. Either<br> > stage can be disabled. The filtering behavior can be controlled using<br> > sysctl(8):<br> > ...<br> > net.link.bridge.pfil_member<br> > Set to 1 to enable filtering on the incoming and outgoing member<br> > interfaces, set to 0 to disable it.<br> <br> 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.<br> Are you confirming that, by moving the IP to the bridge0 interface, this is not possible anymore?<br> <br> <br> <br> > so, if you want<br> > to filter what the host can send and receive on this VLAN, simply use<br> > the "bridge0" interface in your filters.<br> <br> I'll have to investigate this... I guess this is possible, but more complicated.<br> <br> Let's say I have 192.168.1.0/24 net on bridg0/vlan1/tap0, with<br> 192.168.1.1 host<br> 192.168.1.5 VM<br> <br> Before I could do, e.g.:<br> allow tcp from any to me 1000 in via vlan1<br> allow tcp from any to me 2000 in via tap0<br> <br> Now I would probably need something like:<br> deny tcp from 192.168.1.5 to me 1000<br> allow tcp from any to me 1000 in via bridge0<br> allow tcp from any to me 2000 in via bridge0<br> <br> Anyway I'll try and see.<br> <br> <br> <br> <br> <br> > then, you should set net.link.bridge.pfil_local_phys=0 because you are<br> > only filtering layer 3 traffic.<br> <br> I don't follow here, sorry.<br> Isn't this needed in order to isolate the VMs and prevent them free access to the whole base host?<br> <br> <br> <br> <br> > if you are trying to do layer 2 filtering (i.e., you want to filter what<br> > bridge ports can send to each other) then this is more complicated and,<br> > to be honest, i don't use L2 filtering so i'm not an expert on how this<br> > should work, but if you can describe the desired outcome, someone might<br> > be able to suggest something.<br> <br> I used layer 2 filtering in the past, but it was some 20 years ago; I don't remember well how I did it.<br> 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).<br> <br> I'm just a bit suprised: before this required change, I was doing everything without L2 filtering...<br> <br> <br> <br> bye & Thanks<br> av.<br> </div> <hr></div> </blockquote> <br> </body></html> ------=_Part_3059_1985361024.1757580438370--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?940777963.3060.1757580438384>