I’ve had a “basic” OpenWrt setup for a long time. It’s a ZyXel WSM20 working as a vanilla router, attached to a 16 port dumb switch. This switch connects to faceplates throughout the house, one of which is attached to another ZyXel WSM20 running as a dumb AP. I have a mixture of wired and wireless devices connected.
Up until now I have just been letting all my devices mix in a single network, but the number of devices is getting quite large and there are an increasing number of them that I don’t control the software for and I’m starting to worry about security.
What is the correct approach here? I’m fairly sure I should have a separate SSID for the wireless IoT devices, but do I set it up as a guest wireless network? Do I need a VLAN? How should it work with wired IoT devices (such as my TV and music players) that are connected via the dumb switch.
I don’t really want to move to a managed switch, so I’m hoping that I can achieve something reasonable without investing more (other than time).
Thank you for confirming. Would there be any value in setting up a different subnet and allocating the wired IoT devices to it? I could then try to use the firewall to prevent access in the wrong direction. I’m not a networking expert so I completely understand that this might be a stupid idea and/or offer no real benefit.
So having dug further into this, I think I can start by
creating a guest network on my main router
Creating a VXLAN to my access point
Adding the VXLAN to my bridge network
Create another guest wireless network on the access point, forwarding over the VXLAN
Does that make sense?
Also, having followed the guest network instructions I have a network that won’t let me get an IP address. I did update dnsmasq to include my new interface…
Yes. VXLAN is the next level up over VLAN, jumping over the many shortcomings of VLANs.
For example you do not need a managed switch.
You can even pass a "legacy" VLAN trunk over a VXLAN channel.
Only problem is that OpenWrt does not configure "up-to-date" VXLANs very well. It manages point to point over ipv4 fairly well, but if you wanted numerous access points all with guest/iot networks it can be a problem as the full config is not supported via uci - but there are ways round it.
I've lost count of how many times I've encountered a dumb switch that transparently passes through all 802.1Q VLAN traffic. So give it a try. If your dumb switch supports VLAN pass-through, I'm sure using 802.1Q VLANs will perform better on your two mt7621 routers.
The behavior of VLANs through an unmanaged switch is, by definition, undefined. Therefore, there are certainly many switches that will just pass the tagged frames without issue. But there are others that will not pass them, some that will actually strip the tags, and still others that will entirely choke on them.
The ambiguity about what will happen can thus result in the appearance of it working properly, the obvious complete failure, or something in between, including subtle issues that are really hard to pinpoint and debug.
One thing that is certain, though, is that any unmanaged switch that passes the frames transparently (i.e. seems to work without any obvious technical issues) will have two significant downsides:
Reduction in security due to the fact that the VLANs will appear on all ports (since you cannot configure per-port VLAN membership)
The inability to set access ports (i.e. one network: untagged+PVID). If the router's config includes an untagged network on the trunk, that will be accessible on all of the switch ports (as will all of the tagged networks), but you cannot change the per-port configuration to allow untagged access to the other VLAN(s),
This is generally ill-advised. It's always better to use a proper managed switch whenever VLANs are involved. Yeah, it might seem like it's working, but as I've described, this can result in a false sense of security (both literal security as well as the idea that the switch won''t cause issues).
Beyond what psherman already laid out, the OP mentioned a 16-port unmanaged switch. However there barely are real unmanaged switches with >8 ports, those usually are managed switch SOCs hard-strapped to unmanaged operations (avoiding the need for flash/ RAM and rendering them non-configurable), 'success' chances with these are even lower (because they know exactly what VLANs are, but are intentionally dumbed down).
This is what I want, and what I have done with my main router’s guest network, but I would like to have a single SSID and subnet for all of my IoT devices.
I know that IoT devices tend to be a bit mixed with the quality of their WiFi implementations, so I want something where they won’t be roaming subnets if they reconnect to different access points.
Another option would be to set up different guest SSIDs and subnets on each access point and keep everything totally separated. I would then have to “pin” the IoT devices to each AP - this feels like a harder option to manage, and would be less usable for the few movable devices that I have…
I just want to remind that we have switch hardware supported by OpenWrt. I run 2 dlink devices with OpenWrt with only switch config so I don't have do deal with the crap of the vendor firmware....
At least with only OpenWrt in place a user does not need to wrap the head around the crazy config options of some vendors but stays within the OpenWrt ecosystem. Those dlink switches are also quiet cheap.
Based on all of the feedback here I've decided to alter my wiring a little so that I can run VLANs. I don't have the CPU power in my router to VXLAN everything at suitable speeds (500MBps internet plus NAS traffic). I've now got a direct cable run between my two WSM20 boxes, and another going to the 16 port switch.
My goal is to have the direct cable run between the routers work as a trunk with the main lan (id 1, untagged) and IoT LAN (id 17 tagged). Each WSM 20 will then have one port for the main LAN (port 2 untagged) and one port for the main LAN (port 3 untagged). The primary router will use one of these LAN ports to connect the 16 port switch.
I have attempted to set this up, and have managed not to break my default LAN, but my access point IoT bridge doesn't seem to be working. I'm not able to get an IP address from the DHCP on the main router, nor am I able to ping the main router from the access point using the IoT LAN address. Any advice? I'm happy to send config snippets/screenshots if you can point me to what would help.
Sure? Vxlan is by far one of the easiest encapsulation methods because it's just a udp packet with the embedded original packet. No encryption and nothing. So besides some asics offload the vlan tagging there should no real difference to plain routing. Maybe 2 to 5 percent lower...
The chipset in my router is pretty low-power. It's suggested that VXLAN routing would have to be purely in software, and would be limited to 200-300 Mbps. Given that both routers also have to manage WiFi I'd prefer to keep hardware acceleration if at all possible so I can keep the full duplex 1Gbps switching speed. I have to work upstairs and the difference between a stable 500+ Mbps and a choppy 200 Mbps is noticeable, especially with family at home using the network.
Ah ok yes if we just compare switching and routing on these devices which offer some asic switching support and sometimes some hw acceleration then yes you can see a penalty but that wound be the same with and without hw acceleration.
On x86 however you can hardly measure the impact of using vxlan.
I'm now further on, and I think I've done it right. This is the network from the access point:
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 'fdxx:xxxx:xxxx::/48'
option packet_steering '1'
option dhcp_default_duid '00010001xxxxxxxx'
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
config interface 'lan'
option device 'br-lan.1'
option proto 'static'
option ipaddr '192.168.1.2'
option netmask '255.255.255.0'
option gateway '192.168.1.1'
option ip6gw 'fdxx:xxxx:xxxx::1'
list dns '192.168.1.1'
option multipath 'off'
config interface 'wan'
option device 'wan'
option proto 'dhcp'
option auto '0'
config interface 'wan6'
option device 'wan'
option proto 'dhcpv6'
option auto '0'
option reqaddress 'try'
option reqprefix 'auto'
config bridge-vlan
option device 'br-lan'
option vlan '1'
list ports 'lan1:u*'
list ports 'lan2:u*'
config bridge-vlan
option device 'br-lan'
option vlan '17'
list ports 'lan1:t'
list ports 'lan3:u*'
config interface 'IoT'
option proto 'static'
option device 'br-lan.17'
option ipaddr '192.168.2.2'
option netmask '255.255.255.0'
option gateway '192.168.2.1'
option multipath 'off'
I've added the following to the access point firewall
config zone
option name 'IoT'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'IoT'
config forwarding
option src 'lan'
option dest 'IoT'
And the following to to the router firewall
config zone
option name 'IoT'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'IoT'
config rule
option src 'IoT'
option name 'Allow-DNS-IoT'
option dest_port '53'
option target 'ACCEPT'
option enabled '1'
config rule
option src 'IoT'
option name 'Allow-DHCP-IoT'
list proto 'udp'
option dest_port '67'
option target 'ACCEPT'
option enabled '1'
config forwarding
option src 'IoT'
option dest 'wan'
config forwarding
option src 'lan'
option dest 'IoT'
Did I mess anything up? I was a little surprised to be able access LUCI for the router when on the IoT network (but not for the access point, which is expected). I do want to be able to access devices in the IoT network from the lan as my Home Assistant will be lan side and needs to directly contact some of the devices for local control.
