I'm trying to convert an older Openwrt 19 config to new hardware running v23.0.3. I had the vlans set up on the old one perfect and was hoping I could just import the old config into the new router, but that doesn't work. I also tried replicating the config options in Luci but the options are not the same.
On my old config I had 3 vlans. Vlan 1 was for general LAN traffic. It was off for LAN port 1 and WAN and was untagged on LAN ports 2 3 and 4. Vlan 2 was for WAN. It was off for LAN ports 1-4 and untagged for WAN. Vlan 3 was for admin traffic. It was untagged for LAN port 1 and off for everything else. All 3 were tagged for CPU port eth0.
Trying to recreate this setup in Luci on new version, first off I notice br-lan is created by default so it's not possible to set vlan tags on both lan and wan in the same interface. I assume I will need to delete br-lan and create br including all lan and wan ports. First however I just tried something simpler to make lan port 1 have a different IP address and firewall zone.
I was following this tutorial https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial so I just set VLAN 1 to be off for port 1 and untagged on the other lan ports. Then I made VLAN 2 to be untagged on port 1 and off for the other lan ports. Then I made a new interface for port 1 with a new IP address and set DHCP for it. Also made a new firewall zone for it using default settings of input allow, output allow and forward reject.
When I rebooted, I couldn't connect to the device on port 1 or any other port, not even with static IP set. I have no idea what happened, so I had to hard reset. I'm including my old network config file if that helps any.
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fd00:10:10:31::/64'
option packet_steering '1'
config interface 'lan'
option type 'bridge'
option ifname 'eth0.1'
option proto 'static'
option netmask '255.255.255.0'
option ip6assign '60'
option ipaddr '10.31.0.1'
config device 'lan_eth0_1_dev'
option name 'eth0.1'
option macaddr 'ac:ac:ac:ac:ac:ac'
config interface 'wan'
option ifname 'eth0.2'
option proto 'dhcp'
option peerdns '0'
list dns '127.0.0.1'
option type 'bridge'
config device 'wan_eth0_2_dev'
option name 'eth0.2'
option macaddr 'ac:ac:ac:ac:ac:ac'
config interface 'wan6'
option proto 'dhcpv6'
option ifname '@wan'
option peerdns '0'
option reqaddress 'try'
option reqprefix 'auto'
list dns '::1'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option vid '1'
option ports '0t 2 3 4'
config switch_vlan
option device 'switch0'
option vlan '2'
option ports '0t 5'
option vid '2'
config interface 'tun'
option proto 'none'
option ifname 'tun0'
option auto '0'
config interface 'guest'
option type 'bridge'
option proto 'static'
option ipaddr '10.15.0.1'
option netmask '255.255.255.0'
config switch_vlan
option device 'switch0'
option vlan '3'
option ports '0t 1'
option vid '3'
option description 'admin'
config interface 'admin'
option proto 'static'
option ifname 'eth0.3'
option ipaddr '10.22.0.1'
option netmask '255.255.255.0'
config interface 'wwan'
option proto 'dhcp'
Your config has many major issues. It will be much faster to reset and start from scratch. Once you've reset, feel free to set your desired lan subnet/address, but don't make any other changes. Then, post (near default) config and we can help you from there. It's actually pretty easy, as you'll see, but you have to get used to a slightly different paradigm of how to configure the device.
One key piece of info that is also needed -- will the management network be available via wifi, or is it wired (on port lan 1) only?
I made a new bridge device with what I think should be the correct VLAN settings without actually enabling the VLAN so I don't lock myself out again. Let me know if it looks right.
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'acac:acac:acac::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
config interface 'wan'
option device 'wan'
option proto 'dhcp'
config interface 'wan6'
option device 'wan'
option proto 'dhcpv6'
config device
option type 'bridge'
option name 'br'
list ports 'eth0'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
list ports 'wan'
option mtu '1500'
option macaddr 'AC:AC:AC:AC:AC:AC'
option txqueuelen '1000'
option mtu6 '1500'
config bridge-vlan
option device 'br'
option vlan '1'
list ports 'eth0:t'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
config bridge-vlan
option device 'br'
option vlan '2'
list ports 'eth0:t'
list ports 'wan'
config bridge-vlan
option device 'br'
option vlan '3'
list ports 'eth0:t'
list ports 'lan1'
Do you mind to tell us what device do you have?
Where is eth0 coming from in your config?
Did you only used Luci or did you have done manual changes too?
What helped me to convert ancient wisdom was:
Modern Kernel supports vlan filtering on a single bridge interface. Back in the days we needed to have one bridge per vlan. Now everything is one bridge with multiple vlans.
DSA is a nice wrapper around these embedded chips. And a lan* port can be tagged or untagged as with regular enterprise gear.
And the simple notation is no suffix or :t on one of these lan ports per vlan or the port is no member of a vlan at all.
That should cover most aspects of follow and understand the "new" Syntax, and yes I procrastinated the change for over two years too
Thanks. So I deleted the br interface and added the new mgmt interface as you suggested. So lan port 1 is now on mgmt and 234 are on br-lan. This kinda sorta works. DHCP gives out different addresses for the 2 networks, and I set uhttpd to only listen on the management IP address. However, I notice you didn't include any vlans in this setup, so a client attached to lan ports 2-4 can still access access the management interface, which defeats the purpose of having a separate management interface. So how would I set up a vlan to restrict access to only port 1?
Using E8450. eth0 is the default ethernet device name. So far for the network config I have only used Luci, though I have manually edited other files like uhttpd since Luci doesn't give the options I want to change there.
To be clear, this is not a VLAN thing... it's the firewall. You didn't ask for the lan to be prevented from accessing the device. It's easy to fix, though.
I would recommend undoing this change. It doesn't do what you think it will, and it may cause you problems later.
Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:
Yeah, I can use the firewall to restrict access, but I like having control over layer 2. That's why I want to use a VLAN. VLAN + firewall is even better.
VLAN actually only applies to ethernet, and is only relevant if you are passing more than one network on a single port and/or if you have more than one physical interface (i.e. 2 or more ethernet ports or ethernet + wifi).
Yes, but that's because you broke the network interfaces and connectivity . VLANs are a subset of, and often used colloquially as a term for "multiple subnets" -- but they are actually 2 different things. VLANs operate at L2 and are strictly about keeping the streams of traffic separated at L2. However, the network interfaces themselves are at the L2/L3 boundary, and when you attempt to connect from one subnet to another, that happens at L3. The firewall is required at L3 if you wish to restrict that connectivity.
Precisely. That is why I didn't recommend constructing bridge-VLANs for your situation.
Call me stubborn, but I'm going to keep working at it. I wonder if you can explain some earlier comments?
According to netstat, uhttpd is now listening only on the interface I specified and not 0.0.0.0. This is exactly what I had in mind. What were you referring to in this comment?
The listen-on interface does not limit what addresses/networks can access the router. All it does is specify the address that is listening. So, let use an example:
There are two networks: lan (192.168.1.0/24) + guest (10.1.2.0/24).
The router has an address on each network (let's say the .1) -- therefore it has 2 addresses for the same device. You can think of them like nicknames. the router will respond to either address.
Now, if you set the listen-on address to 192.168.1.1, that means the router will only listen to requests to that address.
Importantly, a guest (say 10.1.2.71) can still access the router by simply entering 192.168.1.1.
If we configure the firewall to reject input from the guest network, then it will not be able to access the router, regardless if the listen-on address is 0.0.0.0 or 192.168.1.1 (or even 10.1.2.1).
Setting the listen-on address is not generally considered necessary because it does not limit access, it simply limits the address (or basically the nickname) on which it will listen and respond.
The firewall is the correct way to limit access.
Finally, Setting the listen-on address is not recommended because it could lock you out if you ever change the router's address. So imagine in the above example,, you change the router's address to say 192.168.23.1, but you left the listen-on address set to 192.168.1.1... now, the router doesn't actually have an address on that network, so it's not possible for it to actually receive a connection request. Leaving it unspecified (0.0.0.0) means it will always respond to a network that is allowed input (as configured in the firewall).
The syntax in pretty much every stanza was invalid for modern OpenWrt. It looked like either OpenWrt 19.07 or even 18.06. I don't recall when the changes happened, but it is not valid to use ifname anymore and the bridges must be defined in a device stanza that is separate from the network interface. In fact, your device uses DSA, yet you had swconfig based configurations in the file which will absolutely not work.