Re: Help with bridge and new IP requirements

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.
>  
> 
> 
>