VLANs - Bridge-VLAN vs Port-VLAN on single port LAN

Can someone explain the difference/correct usage of VLAN defined at the port - eth0.10 and the like - and defined at the bridge - br0.10 - and where I should use each?

Using the port on WAN for my ISP-defined VLAN was pretty easy, change wan and wan6 to eth1.10 and that's done.

But now I want to migrate my previous internal VLAN setup, and I'm having issues understanding the proper way to go about it.

The way I have my internal network set up:

5 Subnets:

  • Main: 192.168.1.0/24 VLID 1/Untagged - trusted devices and any IoT I just can't access from main while in a separate subnet
  • IoT: 192.168.2.0/24 VLID 2 - any IoT device polite enough to work in a separate subnet.
  • Guest: 192.168.3.0/24 VLID 3 - mainly just guest wifi
  • Alarm: 192.168.4.0/24 VLID 4 - house's alarm system
  • Testing: 10.0.0.0/24 VLID 10 - homelab testing network

Main and Testing are bridged, and have a firewall rule to prevent connection initiation from IoT to Main.

All the others are isolated in their own bridges.

What's the best way to replicate this in DSA Openwrt?

Do I create 4 bridges, and assign eth0.x ports as appropriate to each?

Do I need to create bridge-VLANs on all of them? Only on the main/iot bridge?

Can I do away with bridges entirely for the VLANs that have to be isolated from everything else?

I've seen examples but nothing with quite the sort of configuration I'm trying to achieve.

The rest of my network gear is UniFi and works perfectly with a untagged/tagged trunk, so that's not a concern.

Let's start with understanding what device you're using... this has everything to do with the structure and syntax of your VLANs.

ubus call system board
cat /etc/config/network

Its an x86 ODROID H4 Ultra. 2 Ports, one for WAN one for LAN.

Network config is currently stock, i plugged it in earlier to check that I could ping out then put my old router back and reset the WAN config, so that I can continue configuring it with the WAN connected to my Testing VLAN

With an x86 device, you don't have a switch, so you'll usually use dotted notation.

Since you've got just one lan port, no bridges are needed....

You'll simply define each network using the device eth0.x (assuming eth0 is the lan port) where x is the VLAN ID. eth0 on its own is the untagged network.

Ok, cool.

Would putting untagged and VLID 2 in a bridge make it easier to route traffic/multicast between the two or does it change nothing (or break things)?

Bridges are basically the same as an unmanaged switch. If you put two or more VLANs into a single bridge, you defeat the purpose of the VLAN.

To handle multicast traffic, you'll want to use the avahi mdns reflector methods.

And for standard routing between VLANs, this is managed by the firewall... the routing engine will do the work based on the allowances/denials of the firewall configuration.

Allright, but then, where do bridge-level VLANs - I've seen it done with dot notation there too - and the "VLAN Filtering" option on bridges come in?

Those are generally for use with devices that have built-in switches (i.e. an all-in-one wifi router).

Got it.

Then, one final question for the night, I saw the default br-lan bridge is assigned to the LAN firewall zone. Can you create more zones? If so where? And is that a good idea if so?

Actually, this is not correct...

the default configuration sets up br-lan as a device. This device is used by the lan network interface, and then that network interface is associated with the lan firewall zone. The distinction is important because it isn't the L2 device, but the L3 interface that is being assigned to the firewall.

Yes, using the firewall config. And it is a good idea if it matches your goals. It probably does in your case.

A firewall zone can have multiple networks associated with it. There are zone-level policies and rules that apply to the firewall zone -- these will apply to all networks within. If you have networks that should be treated with similar policies (at least broadly speaking), you can put them in the same zone and you can make more granular rules if necessary to adjust the firewall allowances/denials according to your goals. For networks that should be treated entirely differently, typically they will go in different zones. There are lots of ways to approach it as the firewall is very flexible.

Right. Devil in the details.

So how's this for a plan when I have some time this week:

  1. I remove the br-lan bridge and the lan interface.
  2. Recreate what was on the lan interface directly on eth0 device.
  3. Make my other VLANs as eth0.x devices.
  4. Rename the LAN zone to 'Trusted'
  5. Assign eth0 "Main" and eth0.2 "IoT" to Trusted
  6. Create another zone as 'Untrusted'.
  7. Assign the other interfaces to it.
  8. ???
  9. Profit.

Or would it make more sense to put Main and IoT on their own separate zones so I can just use the zones in the firewall policies?

I would not remove the lan interface. You can, however, easily remove br-lan and set the device in the lan interface to eth0.

Yes.

Not recommended, but it can be done. There's no technical blocker here, just that you must rename the zone in the other places where it is used within the firewall file. It's extra work with no value added.

Remember, it's the network interfaces you'll assign, not the devices. I'd recommend keeping lan labeled as such (instead of renaming it Main).

As far as the IoT network is concerned, many poeople consider their IoT networks untrusted. But that's up to you.

Sure.

Yes, likely. But that's up to your goals.

Forgot about that. Not that its a lot of work to search/replace in vim, we'll see.

Sure, but its a different level of untrusted, able to receive traffic from LAN and reply to it, and see their multicasts, to a fully doghoused network like Guest.

It's a matter of perspective. Most people don't trust IoT devices because of ... reasons... (I trust the people on my guest network more than my iot devices, but I can't always trust that my guest's have good device security).

I view the IoT and guest networks as equally untrusted and my main lan as trusted. So, I allow the lan to initiate connections to the iot network, but not the other way around. The guest network can be treated the same way, but rarely do I need to connect to a device on the guest network.

Right, perhaps a better term for IoT is "Tolerated" :rofl:

Btw, on switching the lan interface's device from br-lan to eth0 via LuCI it shows a uci del dhcp.lan.ra_slaac line in the changes to be applied, is that fine?

This should be unrelated to the lan device... I'm not sure why changing the device would cause the dhcp services to be changed.

That said, it is IPv6 related, so it's not critical unless you are using IPv6. In that case, you can easily re-add this option in the lan dhcp server section.

1 Like

I will do IPv6, but I'll get v4 up and running first.

BTW, does the "zone forwarding" part of the firewall come into play for what we've been talking about, or do I just handle it via traffic rules?

The forwarding policy within a zone definition applies when there are two or more networks within that zone. This is intra-zone forwarding. It allows or prohibits connectivity between those networks (bidirectionally). You can still craft more specific/granular rules, too. But if a zone only contains one network, this doesn't affect anything.

The forwarding statements (such as lan > wan) are the ones that are used to specify what is allowed in terms of inter-zone connectivity.

So, for the use I have of having IoT and LAN talk to each other, i add forwarding statements for Lan <-> IoT and disable initiating connections from IoT?

Sorry if we're going off-topic btw.

If you have them in the same zone, you'd just ACCEPT zone forwarding.

If they're in different zones, yes you'd do lan > IoT, and maybe IoT > lan. These forwards indicate what is allowed in terms of the initiation of the connection. The response is always allowed. Personally, I only have lan > IoT because I want the lan to be able to initiate connections to the IoT network, but not the other way around (again, I don't trust IoT devices, I don't want them to be able to initiate connections to my trusted network devices).