Hi there,
I have a setup with three wifi APs in my house and I would like to keep a guest network and an IOT network separate from my main LAN. Before upgrading to TOS 5, I used vlan to separate the two networks. In my setup, the omnia is connected via LAN0 to a managed switch, the other APs are connected to this managed switch. I use VLAN ID 1 for my normal network and VLAN ID 11 for my guest network. With turris OS 3 this worked perfectly, but I failed to do this with TOS 5.
To be sure that this is not a result of a broken upgrade, I reflashed TOS 5 via medkit.
After initial setup, I created a guest wifi network via reForis. This did setup a network interface “GUEST_TURRIS”. I tested the guest network and it worked at this point.
Now I would need a bridge between “GUEST_TURRIS” and lan0, vlan ID 11. As far as I understand the manual, this should be achieved by editing the “GUEST_TURRIS” network and adding the interface “lan0.11” in the physical settings tab. I did add the interface and a software vlan “lan0.11” was created.
Unfortunately, this is the point where the guest network did stop working, even through the omnia’s wifi. I can see that device connect and the DHCP server tries to assign an IP address, but after that no traffic is routed and the device disconnects. For wired clients, the ip address is assigned through dhcp and the omnia can receive pakets from the client, but the omnia will not send any pakets to the client, resulting in an unusuable connection.
I can only “revive” the guest network of the omnia if a edit the network config manualy and delete the lan0.11 interface. If a try to remove the interface from the guest network via LUCI, this setting is not saved.
The omnia is the only router I have problems with setting up the vlans. The other routers run openwrt-21.02 with no issues.
Are there further settings required to get the vlans working with TOS 5?
Thank you for your help.
I couldn’t also get it working.
So I ended up splitting into subnets such as:
10.0.1.0
10.0.2.0
etc
I suggest you move to TOS6.0-alpha2 to be able to configure L2/L3 settings in LuCi then you can set up VLANs there without problems. That was one of the reasons I couldnt wait and moved to developer branches
2 Likes
I have changed the branch to HBL and upgraded to TOS6.0-alpha2. I can now configure the VLAN filtering at the bridge device. However, the Turris Omnia does not appear to work as intended.
For example. If I remove the port lan0 from the LAN bridge and add it to the guest-bridge and configure VLAN filtering in order to tag the traffic with VLAN ID 11, the link at this port is no longer brought up. (no light for port 0, link is shown as not connected).
After a complete power cycle, turris will eventually bring up the lan0 port, but the VLAN ID11 is still not working, I can not connect to the guest network bridge from the managed switch connected to port lan0.
Is there any reason why this configuration should not work?
config interface ‘loopback’
option proto ‘static’
option ipaddr ‘127.0.0.1’
option netmask ‘255.0.0.0’
option device ‘lo’
config globals ‘globals’
option ula_prefix ‘fdac:8e62:ab6a::/48’
config interface ‘lan’
option proto ‘static’
option ipaddr ‘192.168.1.1’
option netmask ‘255.255.255.0’
option ip6assign ‘60’
option bridge_empty ‘1’
option device ‘br-lan’
config interface ‘wan’
option proto ‘dhcp’
option ipv6 ‘1’
option device ‘eth2’
config interface ‘wan6’
option proto ‘dhcpv6’
option device ‘@wan’
config interface ‘vpn_turris’
option enabled ‘1’
option proto ‘none’
option auto ‘1’
option device ‘tun_turris’
config device
option type ‘bridge’
option name ‘br-lan’
list ports ‘lan1’
list ports ‘lan2’
list ports ‘lan3’
list ports ‘lan4’
config interface ‘guest_turris’
option enabled ‘1’
option proto ‘static’
option ipaddr ‘10.111.222.1’
option netmask ‘255.255.255.0’
option ip6assign ‘64’
option device ‘brg-turris.11’
config device ‘brg_turris’
option name ‘brg-turris’
option type ‘bridge’
option bridge_empty ‘1’
list ports ‘lan0’
config bridge-vlan
option device ‘brg-turris’
option vlan ‘11’
list ports ‘lan0:t’
Any hints are appreciated, but after reading through several other forum posts and issues in the github, I must assume that the switch functionality of the turris omnia is fundamentally broken since TOS 4.x has never been restored with TOS 5.X and is still broken in TOS 6 alpha. I am afraid that the best solution is buying another cheap tp-link device and replacing my omnia.
I don’t know where these “config device” blocks are coming from. You don’t need them. Just define what you want as “interface” of type “bridge”. TOS takes care of the rest.
config globals 'globals'
option ula_prefix 'fdac:8e62:ab6a::/48'
config interface 'loopback'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
option ifname 'lo'
config interface 'wan'
option proto 'dhcp'
option ifname 'eth2'
option ipv6 '1'
config interface 'wan6'
option proto 'dhcpv6'
option ifname '@wan'
# Main LAN (VLAN 1)
config interface 'main_lan'
option type 'bridge'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '64'
list ifname 'lan0.1'
list ifname 'lan1'
list ifname 'lan2'
list ifname 'lan3'
list ifname 'lan4'
# Guest LAN (VLAN 11)
config interface 'guest_lan'
option type 'bridge'
option proto 'static'
option ipaddr '10.111.222.1'
option netmask '255.255.255.0'
option ip6assign '64'
option ip6hint '111'
list ifname 'lan0.11'
# IoT LAN (VLAN 33)
config interface 'iot_lan'
option type 'bridge'
option proto 'static'
option ipaddr '10.333.222.1'
option netmask '255.255.255.0'
option ip6assign '64'
option ip6hint '333'
list ifname 'lan0.33'
config interface 'vpn_turris'
option enabled '1'
option proto 'none'
option auto '1'
option device 'tun_turris'
1 Like
From your config, it looks like you didn’t add the LAN bridge to lan0 as a tagged port, only lan1-4 as untagged.
There’s an arguably easier way to configure bridging with multiple VLANs. Just make one bridge for everything, and then use vlan filtering to separate them out. Something like this (I call it br-main):
config interface 'lan'
option device 'br-main.1'
option proto 'static'
option ip6assign '60'
option _turris_mode 'unmanaged'
list ipaddr '192.168.1.4/16'
option gateway '192.168.1.1'
list dns '192.168.1.1'
config device 'br_main'
option name 'br-main'
option type 'bridge'
option bridge_empty '1'
option acceptlocal '1'
list ports 'eth2'
list ports 'lan0'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
config interface 'iostuff'
option proto 'none'
option device 'br-main.7'
config bridge-vlan
option device 'br-main'
option vlan '1'
list ports 'eth2:t'
list ports 'lan0:u*'
list ports 'lan1:u*'
list ports 'lan2:u*'
list ports 'lan3:t'
list ports 'lan4:t'
config bridge-vlan
option device 'br-main'
option vlan '7'
list ports 'eth2:t'
list ports 'lan3:t'
list ports 'lan4:t'
config device
option vid '1'
option ifname 'br-main'
option name 'br-main.1'
option acceptlocal '1'
option type '8021q'
config device
option vid '7'
option ifname 'br-main'
option name 'br-main.7'
option ipv6 '0'
option type '8021q'
Then, the wireless config:
config wifi-iface 'default_radio0'
option device 'radio0'
option mode 'ap'
option disabled '0'
option ssid 'removed'
option key 'removed'
option ifname 'lan5g'
option network 'lan'
option encryption 'psk2'
config wifi-iface 'default_radio1'
option device 'radio1'
option mode 'ap'
option disabled '0'
option ssid 'removed'
option key 'removed'
option ifname 'lan2g'
option network 'lan'
option encryption 'psk2'
config wifi-iface 'wifinet3'
option ssid 'removed'
option encryption 'sae-mixed'
option device 'radio1'
option mode 'ap'
option network 'iostuff'
option key 'removed'
1 Like
You created two bridges. I use one br-lan with all ports like lan0-4 and wireless interfaces in it and even lxc veth interfaces. And just enabled VLAN filtering and assigned each VLAN id to separate network. And everything works.
Who are you responding to? If it’s my post, there is only one bridge when all is said and done, though the ports (both physical and virtual) are separated by VLANs. OpenWRT will figure out what you mean if you attach the wireless interface to a bridge VLAN interface.
# brctl show
bridge name bridge id STP enabled interfaces
br-main 7fff.04f021232d7e no testnet
lan4
lan2
lan0
lan5g
lan2g
lan3
wlan1-1
lan1
eth2
Sorry I was responding to @roemmic9 I thought it was clear. Your configuration is almost the same as mine. Just different interfaces names:
root@router:~# brctl show
bridge name bridge id STP enabled interfaces
br-lan 7fff.02f021232624 no home0
lan4
lan2
lan0
veth-openvas
guest0
iot0
home1
test0
lan3
lan1
guest1
iot1
Thank you for your help. However, I could not solve my problems that way (I was having additional problems when wifi devices would roam between a wifi network of the turris and a second access point pluged into one of the lan ports of the turris.)
One of the work-arounds posted here relating to the roaming devices issues actually also solved my vlan issues on TOS 5.4.1. The trick appears to be to force all trafic through the CPU and not to rely on any hardware accelerated operations of the turris as this is completely broken with the switch to DSA.
This is now the config for TOS 5.4.1 with working VLAN and no problems with my roaming wifi devices:
config interface ‘lan’
option type ‘bridge’
option proto ‘static’
option ipaddr ‘192.168.1.1’
option netmask ‘255.255.255.0’
option ip6assign ‘60’
option bridge_empty ‘1’
option ifname ‘eth1.1 lan0 lan1 lan2 lan3 lan4’
config interface ‘wan’
option proto ‘dhcp’
option ipv6 ‘1’
option ifname ‘eth2’
config interface ‘guest_turris’
option enabled ‘1’
option type ‘bridge’
option proto ‘static’
option ipaddr ‘10.111.222.1’
option netmask ‘255.255.255.0’
option bridge_empty ‘1’
option ip6assign ‘64’
option ifname ‘lan0.11’
As the problems with VLANs and roaming devices are present since TOS 4 and are still present in the latest TOS 6 preview I am realy afraid of the next upgrade of the OS to TOS 6.
Update to TOS 6 happened today - and as I feared my configuration that worked fine got broken.
To get my vlan 1 working again, I had to remove the interface eth1.1 from my lan-bridge. I had added this interface as a workaround to solve the roaming wifi devices issues. Furtunately, this workaround appears to be no longer necessary, the wifi devices can now roam and exchange data with devices wired to the lan ports of the turris without having to wait several minutes for old mac tables to time out.