Adding a VLAN to a transparent filter bridge

[Taro]

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
 

[pfry]

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.

[Monviech (Cedrik)]

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.

[Taro]

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.

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.

[Patrick M. Hausen]

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.

[Taro]

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.

[Patrick M. Hausen]

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

[pfry]

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

[Patrick M. Hausen]

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

[pfry]

That's why I mentioned outbound NAT.[...]

Ha! Missed it completely. Double NAT is undesirable, but a solution.

[Taro]

MHO 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

[Patrick M. Hausen]

Outbound on the bridge interface with only the VLAN IP network specified as source.

[Taro]

still doesn't work



are those settings correct?

[Patrick M. Hausen]

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.

[pfry]

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.

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.