Lan ports aren’t accessible for WiFi client if VLAN's enabled

Hi guys, I have a very weird issue regarding vlan

I have the following devices configured:
01

This is the relevant part of the /etc/config/network

config interface 'lan'
    option proto 'static'
    option ip6assign '60'
    option _turris_mode 'managed'
    list ipaddr '192.168.66.1/24'
    option device 'br-lan.66'
    option defaultroute '0'

config device 'br_lan'
    option name 'br-lan'
    option type 'bridge'
    option ipv6 '0'
    list ports 'lan0'
    list ports 'lan1'
    list ports 'lan2'
    list ports 'lan3'
    list ports 'lan4'
    option promisc '1'

config bridge-vlan
    option device 'br-lan'
    option vlan '66'
    list ports 'lan0:t'
    list ports 'lan1:u*'
    list ports 'lan2:u*'

config device
    option vid '66'
    option type '8021q'
    option name 'br-lan.66'
    option ifname 'br-lan'
    option ipv6 '0'
    option promisc '1'

This is the wifi config

config wifi-device 'radio0'
        option type 'mac80211'
        option path 'soc/soc:pcie/pci0000:00/0000:00:02.0/0000:02:00.0'
        option country 'CH'
        option cell_density '0'
        option band '5g'
        option htmode 'HE160'
        option channel '36'

config wifi-device 'radio1'
        option type 'mac80211'
        option path 'soc/soc:pcie/pci0000:00/0000:00:03.0/0000:03:00.0'
        option band '2g'
        option country 'CH'
        option cell_density '0'
        option htmode 'HT40'
        option channel '3'

config wifi-iface 'wifinet4'
        option ssid 'House of Ping'
        option encryption 'psk2'
        option device 'radio0'
        option mode 'ap'
        option network 'lan'
        option key '********'
        option ft_over_ds '0'
        option mobility_domain '6969'
        option ft_psk_generate_local '1'
        option ieee80211r '1'

config wifi-iface 'wifinet3'
        option ssid 'House of Ping'
        option encryption 'psk2'
        option device 'radio1'
        option mode 'ap'
        option network 'lan'
        option key '******'
        option ft_over_ds '0'
        option mobility_domain '6969'
        option ft_psk_generate_local '1'
        option ieee80211r '1'

I also have configured corresponding wifi networks. Now here comes the strange part, as long as my clients are connected to the wifi anything works like a charm, I can ping clients within the respective vlan e.g. my desktop is connect via wifi in the LAN gets the IP 192.168.66.54 and can ping my notebook which is also connected to the WIFI in the same LAN with the IP 192.168.66.55. (edited)

If I connect my Notebook directly on LAN port 1 which is untagged for LAN i successfully get an IP like 192.168.66.42. I can access the internet, no problemo. But I’m unable to ping or get pinged in the 192.168.66.1/24 subnet. I don’t get it, what did I miss? Any ideas? O btw. what is the option _turris_mode 'managed' doing?

You have to set some firewalli rules to allow communication between two VLAN networks, because VLAN is originally meant for splitting networks (networks with dofferent ip subnets).

Your network configuration seems weird for me, but I am not a proffessional.

BUT, if you want only to connect LAN and WiFi into one network you definitely don´t need to use VLAN!
I would reccomend you to reset your router completely and set your wifi via reForis. This is the easiest way. Then it should work for you.
OR you can set all this via LuCI, where you shoudl attach your wifi network to the LAN zone.

Hope, I wrote this clear.and simple :slight_smile:

Yes for sure, I did just left out the other parts which are not relevant :wink: The issue is also not communicating between VLAN’s since I effectively want the segregation, in fact thats the whole point I’m using VLAN’s.

The issue is that clients on the same VLAN cannont communicate to each other if one is connected via Ethernet and one is connected via WiFi.

I’m also aware of this issue: [Omnia] kernel's bridge FDB not reconciling switch's ATU (#165) · Issues · Turris / Turris OS / Turris Build · GitLab
But it seems fixed, and is probably not correlated because no mather how long I wait it doesn’t just start to work. Moreover those issues seem more roaming related I guess.

What exactly do you think is weird about the config?

I guess @jkl has exactly the same issue:

I haven’t upgraded though

I just realized that in reforis no LAN assignments are there. Might this be the issue?

Check Wireless settings in LuCi for your network if Isolate clients is set or not. This could prevent client-to-client communication.

It’s not set, and also WifFi ↔ WiFi client communication works fine

That was one of “strange” settings I have mentioned, but again I am no professional. You definitely should try to assign some LAN port to LAN zone.

I had a similar issue, where I had configured a single bridge to manage all the VLAN settngs. The lan and guest networks had been defined with just the VLAN ports from this bridge. When the wireless cards where then added to the networks, clients could obtain IP addresses from the router and successfully connect to the internet via the wan interface, but not connect to wired hosts on the same subnet.

In the end I resolved this by creating additional br-lan and br-guest interfaces that bring the wired VLAN ports and the wireless interfaces together. This allows traffic from the wireless network to flow to the correct VLAN ports.

Excerpt from /etc/config/network:

config interface 'lan'
        option proto 'static'
        option netmask '255.255.255.0'
        option ipaddr '192.168.11.254'
        option ip6assign '64'
        option ip6hint '0xb'
        option device 'br-lan'

config interface 'wan'
        option device 'eth2'
        option proto 'dhcp'
        option delegate '0'

config interface 'guest'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6hint '0xc'
        option ipaddr '192.168.12.254'
        option ip6assign '64'
        option device 'br-guest'

config device
        option type 'bridge'
        option name 'br-switch'
        list ports 'lan0'
        list ports 'lan1'
        list ports 'lan2'
        list ports 'lan3'
        list ports 'lan4'

config bridge-vlan
        option device 'br-switch'
        option vlan '11'
        list ports 'lan0:u*'
        list ports 'lan3:t'
        list ports 'lan4:t'

config bridge-vlan
        option device 'br-switch'
        option vlan '12'
        list ports 'lan1:u*'
        list ports 'lan2:u*'
        list ports 'lan3:t'
        list ports 'lan4:t'

config device
        list ports 'br-switch.11'
        option type 'bridge'
        option name 'br-lan'

config device
        list ports 'br-switch.12'
        option type 'bridge'
        option name 'br-guest'

Example for wifi interface from /etc/config/wireless:

config wifi-iface 'guest_iface_1'
        option device 'radio1'
        option mode 'ap'
        option wpa_group_rekey '86400'
        option key 'xxxxxxxxx'
        option ifname 'guest_1'
        option ssid 'Turris-Omnia-Guest'
        option encryption 'sae-mixed'
        option wpa_disable_eapol_key_retries '1'
        option network 'guest'

Note that the reForis interface seems to make some assumptions about the naming and content of the network bridges, and with the above there may not be a valid lan or guest interface shown in the Network Settings > Interfaces page. However, this can be easily configured via the Luci interface.

2 Likes

Hi @magnus
Thank you so much this finally did the trick! Very strange that a second device is required. This seems to be different compared to stock openWRT. Do you have any idea why this is required?

Yes, that’s what I assumed in the first place. I don’t care about reForis anyways, never really used it much. I don’t understand why turris is spending this much effort into reForis, I don’t get the point. In my opinion the Omnia is an enthusiast router, so why bother with a fancy pancy UI. I would rather much prefer to have the perfect router for openWRT. But what do I know :slight_smile:

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.