Hello Everyone
I'm currently running a opnsense as a transparent filter bridge since my current ISP doesn't allow anything else. Since I want to play around a bit with different zones I'm now trying to set up an additional VLAN to separate the IOT devices. Behind the Opensense is a Ubiuity Switch with several additional switches + APs
The current running Network is untagged and the ISP router is acting as gateway on 192.168.1.1
🌐 WAN
|
|
🔌 ISP Router (192.168.1.1)
|
|
🛡� OPNsense Firewall
|
|
+-----------------------------+
| OPNsense Firewall
|
| IN (igc0)
| Connected to Untagged VLAN
| 192.168.1.0/24
|
| OUT (igc1)
| Connected to ISP Router
| 192.168.1.1
|
| VLAN20 (igc3)
| Connected to IOT Network
| 192.168.1.20/24
+-----------------------------+
|
|
📡 Ubiquity Infrastructure
| |
| |
🌐 Untagged VLAN 🌐 IOT Network (VLAN 20)
192.168.1.0/24 192.168.1.20/24
(Same as ISP Router)
igc0 + igc0 are in bridge mode and everything is fine so far. I have 5 ports in total so I added another cable to igc3 on opnsense with the VLAN-20, created an interface on it (192.168.20.1) and also created a new tagged wifi on the ubiquity. This network is also working fine and the clients in it can see each other, however they have no internet connectivity.
Is it even possible with this setup to access use the gateway located in the untagged network from the IOT network? The more I read and think about it the more confused i get. Do i have to create another bridge between OUT and VLAN20 or is this unnecessary and the interface enough, but then how do I add a route from 192.168.20.1 to 192.168.1.1?
Thanks in advance
A bridge is normally used to filter multiple ports within a single IP subnet, so while you can add more ports to your bridge, differentiating them at the port level is effectively impossible and differentiating at the IP level can be less than elegant (e.g. via priority/DHCP tags set on the client machines), especially if you don't control address allocation. You could route on igc3 (by assigning an IP to your bridge, making it non-transparent), but communicating with the gateway would require either configuration on the gateway or NAT (using the bridge IP) on the firewall.
If you simply wish to allow for communication between the bridge subnet and igc3 but not with the gateway itself (i.e. no Internet access for devices not on the bridge), you could assign an address to the bridge (directly or via DHCP from your gateway) and use the firewall to route between the bridge and igc3. Routing for the bridge clients will be less than elegant if you do not control gateway assignment (requiring e.g. manual configuration on each client or policy routing on the firewall). If your gateway allows any unassigned IP within 192.168.1.0/24 to function, you could assume control of address allocation, but I can't think of an elegant way to do so (it would require a filter external to the firewall).
I may have overlooked other possibilities (e.g. proxy ARP?). Of course there are solutions outside of OPNsense.
If the ISP Router is configurable it would be simpler to create a separate subnet on the OPNsense for each LAN (and VLAN), and then set up static route(s) on the ISP router.
That way you have clean L3 separation, no double NAT (as you would deactivate NAT on the OPNsense), and no bridge.
Quote from: pfry on January 06, 2026, 11:13:08 AMIf you simply wish to allow for communication between the bridge subnet and igc3 but not with the gateway itself (i.e. no Internet access for devices not on the bridge), you could assign an address to the bridge (directly or via DHCP from your gateway) and use the firewall to route between the bridge and igc3.
I may have overlooked other possibilities (e.g. proxy ARP?). Of course there are solutions outside of OPNsense.
Thanks for your response, I want exactly the opposite. My goal is to have (in the best case) the current untagged network as it is with the ISP Router/Gateway also in it and an additional tagged VLAN that has access to the internet but not to the untagged network. I might reconfigure everything however at the moment I am looking for the best way to get a configuration like this running since I have no option of ditching the router and it also doesn't support a bridge config.
You should be able to add the tagged VLAN, assign an IP address to it and activate DHCP service, then add a firewall rule that permits everything except your local network as a destination.
this is where I am stuck at the moment. I have added the VLAN and created an interface on it. DHCP works also.
IP of the interface is 192.168.20.1 I can ping this one from a test client within.
After adding an interface to the untagged VLAN (192.168.1.10) I can now ping this address from the VLAN20 testclient, however I can't ping any other client in the untagged network or the ISP router.
I have yet to find a Rule that allows this or is there any other config needed? I've tried an allow all rule in both directions for testing on the IN interface but this did not help.
IMHO you should (if you did not already) place an IP address in the 192.168.1.0/24 network on the bridge interface and configure the ISP router as the default gateway.
With that in place you need:
- an IN permit rule on the new VLAN interface
- a NAT rule on the bridge interface with the new VLAN as source network
Quote from: Patrick M. Hausen on January 06, 2026, 04:17:53 PMMHO you should (if you did not already) place an IP address in the 192.168.1.0/24 network on the bridge interface and configure the ISP router as the default gateway.[...]
Isn't there still an issue with the route from the gateway to the igc3 subnet? I'm assuming (but not certain) that the gateway is not user-configurable, which complicates Internet access. (Cedrik's solution is the obvious one, if the gateway is configurable.)
The clients on the bridge would not be accessible from the routed subnet (and vice-versa) due to the lack of a route (as desired; although this would change if one is added to the gateway), and could (should) be filtered in any case.
Interface-based filters on the bridge interfaces would be useful here (allowing port-based differentiation on the bridge), but (apparently) not possible with pf. (I have tested this - pf will not evaluate interface filters on bridge members regardless of net.link.bridge.pfil_* settings; I have not tested the other filter systems.)
Quote from: pfry on January 06, 2026, 04:51:59 PMQuote from: Patrick M. Hausen on January 06, 2026, 04:17:53 PMMHO you should (if you did not already) place an IP address in the 192.168.1.0/24 network on the bridge interface and configure the ISP router as the default gateway.[...]
Isn't there still an issue with the route from the gateway to the igc3 subnet? I'm assuming (but not certain) that the gateway is not user-configurable, which complicates Internet access. (Cedrik's solution is the obvious one, if the gateway is configurable.)
That's why I mentioned outbound NAT.
Quote from: Patrick M. Hausen on January 06, 2026, 04:57:11 PMThat's why I mentioned outbound NAT.[...]
Ha! Missed it completely. Double NAT is undesirable, but a solution.
Quote from: pfry on January 06, 2026, 04:51:59 PMQuote from: Patrick M. Hausen on January 06, 2026, 04:17:53 PMMHO you should (if you did not already) place an IP address in the 192.168.1.0/24 network on the bridge interface and configure the ISP router as the default gateway.[...]
Isn't there still an issue with the route from the gateway to the igc3 subnet? I'm assuming (but not certain) that the gateway is not user-configurable, which complicates Internet access. (Cedrik's solution is the obvious one, if the gateway is configurable.)
The clients on the bridge would not be accessible from the routed subnet (and vice-versa) due to the lack of a route (as desired; although this would change if one is added to the gateway), and could (should) be filtered in any case.
Interface-based filters on the bridge interfaces would be useful here (allowing port-based differentiation on the bridge), but (apparently) not possible with pf. (I have tested this - pf will not evaluate interface filters on bridge members regardless of net.link.bridge.pfil_* settings; I have not tested the other filter systems.)
what I was able to achieve in the meantime, I've configured the ISP router as upstream gateway and now when I issue a ping/nslookup on an address, the resolution is working fine and the correct IP is shown, however I don't get a ping response.
I wanted to test NAT however I'm not sure how to configure it.
Do i have to use port-forward for all relevant ports? or Outbound, however I've disabled this since I've read that it should be disable when using bridge mode
Outbound on the bridge interface with only the VLAN IP network specified as source.
still doesn't work
(https://i.postimg.cc/8Pz5SNvt/Screenshot-2026-01-06-195349.png)
are those settings correct?
(https://i.postimg.cc/WpBd0Qqg/Screenshot-2026-01-06-195838.png)
Looks good. I don't have a transparent bridge so I cannot test anything. Try to use a packet trace to see what happens on the wire.
Quote from: Patrick M. Hausen on January 06, 2026, 08:11:50 PMLooks good. I don't have a transparent bridge so I cannot test anything. Try to use a packet trace to see what happens on the wire.
I agree - looks OK. I have a non-transparent bridge, and now so does Taro. Heh. But it works for me. How does the firewall's gateway look? I'd check "System: Routes: Status" - the default should be listed, pointing to your gateway. And just to be certain, double-check the interface address for the bridge.
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".
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
Quotemy 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:
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.
Quote[...]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):
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
@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.
Quote from: Patrick M. Hausen on January 06, 2026, 10:50:11 PM[...]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.
Quote from: pfry on January 06, 2026, 11:16:29 PMWhat 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.
Heh. Consider the target NAT data flow.
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