From nobody Thu Sep 11 08:47:18 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 4cMrls1HWrz62fvv for ; Thu, 11 Sep 2025 08:47:21 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp-relay-int-backup.realworks.nl (smtp-relay-int-backup.realworks.nl [87.255.56.188]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cMrlr5mcYz4Nwg for ; Thu, 11 Sep 2025 08:47:20 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Authentication-Results: mx1.freebsd.org; none Received: from smtp-relay-int-backup.realworks.nl (crmpreview5.colo2.realworks.nl [10.2.52.35]) by mailrelayint2.colo2.realworks.nl (Postfix) with ESMTP id 4cMrlp4MLTz1QJ; Thu, 11 Sep 2025 10:47:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1757580438; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=8F0ZzTc5S7VAJqKNxMx6ieb3Ks/vcqBnsqPwbr0giyY=; b=v3gU0zSOxdHMd3BFkrE04A5cxGxvShroLbIyg34JVSdJhfTltybGIgkZXvWrIGkSsrKUD5 T+H9Qx6ImL7q9OTCaTk65A3JVYS4Vsw/S1X64RUco1vBHhtYdKlF5HHvLo2qcld0gmCWku ZuBvW2+2rg2o8w6DZvdzcSB+h7PZpc3yOQdKlEOowDjTlqp6xjWzkis30mMuJ7sONbzmNZ /2z9YPvZRXQ+A3THM2T+3uINDKW1AM+o1Mp8nyChM9pzGVc4WW8qXjEzKLfgm5VLKeUQzg sKaTjLhUAjat/s6CojUWIF0KLLWzoGBOn8Y2LZg6pxo4JxS/0f94y9FJEqho6w== Received: from crmpreview5.colo2.realworks.nl (localhost [127.0.0.1]) by crmpreview5.colo2.realworks.nl (Postfix) with ESMTP id 6D4D5C018B; Thu, 11 Sep 2025 10:47:18 +0200 (CEST) Date: Thu, 11 Sep 2025 10:47:18 +0200 (CEST) From: Ronald Klop To: Andrea Venturoli Cc: freebsd-net@freebsd.org Message-ID: <940777963.3060.1757580438384@localhost> In-Reply-To: References: <24b8c39e-b1a3-4cd3-accc-c86a03e21689@netfence.it> Subject: Re: Help with bridge and new IP requirements 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 Content-Type: multipart/alternative; boundary="----=_Part_3059_1985361024.1757580438370" X-Mailer: Realworks (765.87) X-Originating-Host: from (83-81-212-149.cable.dynamic.v4.ziggo.nl [83.81.212.149]) by crmpreview5.colo2.realworks.nl [10.2.52.35] with HTTP; Thu, 11 Sep 2025 10:47:18 +0200 Importance: Normal X-Priority: 3 (Normal) X-Originating-User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:142.0) Gecko/20100101 Firefox/142.0 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:38930, ipnet:87.255.32.0/19, country:NL] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cMrlr5mcYz4Nwg ------=_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 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 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--