Adding a VLAN to a transparent filter bridge

[Patrick M. Hausen]

Waitaminute ... in the transparent bridge setup does the filtering take place on the bridge or on the member interfaces? I.e. how is this ...something...pfil_member tunable set?

My NAT advice assumed firewall rules are on the bridge. But I suspect contrary to a LAN bridge this might not be the case here. Because transparent "filtering".

[Taro]

my system routes look like this

Routing tables

Internet:
Destination        Gateway            Flags         Netif Expire
default            192.168.1.1        UGS            igc0
localhost          link#7             UH              lo0
192.168.1.0/24     link#1             U              igc0
192.168.1.1        link#3             UHS            igc2
192.168.1.2        link#7             UHS             lo0
OPNsense           link#7             UHS             lo0
192.168.20.0/24    link#11            U            vlan01
192.168.20.1       link#7             UHS             lo0

I've also checked the firewall log and the rule seems to work also

__timestamp__   2026-01-06T20:57:55
action   [pass]
anchorname   
dir   [out]
dst   193.99.144.85
dsthostname   
ecn   
id   41301
interface   igc0
ipflags   DF
ipversion   4
label   let out anything from firewall host itself
length   84
offset   0
protoname   icmp
protonum   1
reason   match
rid   fae559338f65e11c53669fc3642c93c2
rulenr   58
src   192.168.20.103

[pfry]

my system routes look like this[...]

That's not what I would expect. I would expect the default route to be applied to the bridge, as well as the 192.168.1.0/24 connected route (via the address assignment). The bridge member interfaces should not have assigned IPs.

Here's a partial list from my firewall:

Code Select Expand

ipv4        default        47.190.83.1 UGS 1500  bridge0 EDGE
ipv4        10.101.11.0/24 link#23     U   1500  bridge1 TRUST
ipv4        10.101.11.1    link#7      UHS 16384 lo0     Loopback
ipv4        47.190.83.0/24 link#20     U   1500  bridge0 EDGE
ipv4        47.190.83.202  link#7      UHS 16384 lo0     Loopback

EDGE/bridge0 is my internet-connected bridge, assigned 47.190.83.202/24 (a public static in my case); TRUST/bridge1 is the equivalent of your vlan01, assigned 10.101.11.1/24 (an internal interface; mine happen to be bridges). Yours may not look quite the same, but what I said above applies. It looks to me like you'll have to move some of your configuration elements (addresses, rules) from igc0 to the bridge. Your NAT entry was correct.

[...]I've also checked the firewall log and the rule seems to work also[...]

I would expect log entries for NAT'd sessions to look something like this (assuming logging enabled on the relevant rules; ingress filter entry at the bottom, egress at the top; note the source flow change):

Code Select Expand

EDGE  Out 2026-01-06T14:49:07-06:00 TCP 47.190.83.202:41132 89.149.225.137:443 pass let out anything from firewall host itself
TRUST In  2026-01-06T14:49:07-06:00 TCP 10.101.11.166:50560 89.149.225.137:443 pass TRUST: Pass any from TRUST net to any


[Patrick M. Hausen]

@pfry this is all true and dandy for a LAN bridge or any bridge intended to turn 2 or more interfaces into a "switch". Specifically the part about the IP addresses not being assigned to any bridge members. In FreeBSD this is explicitly forbidden.

Yet I wonder if in the case of a transparent filtering bridge you can do the same of if you necessarily need another dedicated management interface. Of course that would be easiest for the OP.

- have a transparent filtering bridge without any IP address, not on the bridge, not on the members
- have a dedicated management interface in the network managed by the ISP router with an IP address and a default gateway
- NAT outbound on that interface for your new VLAN

Again: untested but that looks like the cleanest way to implement this to me. Your switch (which I assume you have when running a transparent bridge setup) can take care of all the separation into VLANs.

[pfry]

[...]Yet I wonder if in the case of a transparent filtering bridge[...]

What would be the purpose of a transparent bridge with an additional interface connected and assigned an IP from the bridged subnet? That's just a non-transparent bridge with extra steps. It may be doable, and, of course, it's up to the individual, but offhand I'd expect it to be a bit loopy. Could be an interesting experiment for our guinea pig, I suppose.

[Patrick M. Hausen]

What would be the purpose of a transparent bridge with an additional interface connected and assigned an IP from the bridged subnet?

As far as I understand most people deploying the transparent filtering bridge use a dedicated management interface. Connected to the "inside" of the filtering bridge by the switch in the setup. That interface is used for OPNsense's Internet uplink (besides UI access, obviously) and the bridge is strictly for filtering without changing the ISP router topology, DHCP server and the like.

[pfry]

Heh. Consider the target NAT data flow.

[Taro]

I've did some additional testing, however nothing seems to work. I guess I'll switch my Internet provider to someone that allows access without using their own hardware