What Switch and AP running with latest OpenWrt would you recommend me for my new IoT network?

Hello, I am already running OpenWrt on my router, but would like to expand my network to have a separated VLAN for IoT devices, since I heard it's impossible to achieve that just with a router. For that I think I need a switch and a AP, which supports OpenWrt. Any recommendations? :slight_smile:

The IoT network so far will only contain my vacuum cleaner robot.

My criteria:

  • Available in the EU (at best on Amazon)
  • Support 2.4GHz, 5/6 GHz is completely optional (I would rather save money, since I don't need that for IoT devices)
  • Obviously support VLANs
  • Runs latest OpenWrt and will in the future
  • Must be priceworthy
  • Can be from the used market, I just need the recommended models :wink:
  • Nice to have: the flashing doesn't require UART/SPI etc. flashing just SFTP or via the interface

That's incorrect. In fact, you need your router to be able to segregate networks via VLAN. Luckily, OpenWrt can do that.

It would be helpful to know which maker and model you are running OpenWrt on right now. Is it really just a router, no Wifi?

A switch is only needed if you need a bigger number of network ports than the router can provide, and/or if your network is spread farther out. You didn't mention the router on which you are running OpenWrt.

As for the AP, it doesn't have to be anything special. Virtually any OpenWrt-supported access point (or router, demoted to AP) can do what you want. The selection mainly depends on what exactly you expect from the access point.

Thank you for your reply. So I don't need to buy any additional hardware and just setup a new 2.4GHz radio or something like that?

I run Tp-Link Archer C7 with OpenWrt

This is what my switch submenu looks like:

The screenshots in the guide are a tad outdated, but basically you want to set up a guest network, just for a "special kind of guest".

As a sidenote: While you can absolutely run regular and guest/iot networks on the same Wifi, with two SSIDs, I found it unnecessary since some of my IOT devices are the only ones that still depend on 2.4GHz while my regular devices all want to use 5GHz anyway. If it is the same for you, you can spare yourself the VLAN separation entirely, just hook the 2.4GHz wifi up to the IOT-LAN, and the 5GHz wifi to the regular LAN, no VLANs required because you actually don't need to separate anything that isn't already separate.

You're sure that 2.4GHz and 5GHz connected devices are physically separated? I already have two separate radios setup (2.4GHz and 5GHz)

Ok, that is an option for me. How do I exactly do that? The link you gave me is for setting up a guest network

An "IOT network" is just a "guest network" by another name, both are networks that are separated from -- and don't have access to -- the main network. They work and are set up completely the same. If it makes you feel better, you can just name it "iot" instead of "guest" :wink:

OK, I followed the tutorial, setup the new radio and setup a new interface but now the device is unmanaged for the IoT interface and there are no IP address options for me like in the screenshot... What do I need to do next then? I tried selecting the IoT Wireless network as the device but it did not help it seems...

I also tried setting the Protocol to DHCP Client but still it fails when connecting because it doesn't get a IP handed out and I don't see how to setup that...

I managed to set it up following this for the first three chapters in the GUI:

But now I can't access my DNS sinkhole in another interface, how do I solve this by also isolating clients?

Also now when I ping the IoT network gateway from the 5GHz WiFi Network I ping it successfully (which is strange).

But thank god when I ping the client of the IoT gateway it says destination unreachable, so at least that works...

Any idea how to make the gateway unpingable from the regular network or is it not even necessary to setup?

My main problem now is somehow making all traffic from the IoT network also go thru my DNS sinkhole..

I think the 'iot' gateway address is pingable because it is on the C7 router so the routing and IP processes in the kernel/drivers sees that it is itself and replies.
If the hosts on the regular network are trusted by you, you may not need to try to stop the ability to ping the 'iot' gateway address from them.

For the DNS sinkhole issue, if it is a case of having DNS running on the C7 with an additional DNS sinkhole, but the C7 is not redirecting/forwarding to your sinkhole there are probably a few options depending on your setup.

Each time you get something new working, I recommend that you save the config to your pc. Adjust the name of the backup file so you know what is working so you can restore to it if you want.
Select "Backup" in the "System" menu.
Click on "Generate archive"
On your pc, add a bit of description to the file name or track the description in a document etc..

If you just want all DNS queries from every device in your 'iot' network to go to your sinkhole then setting the DHCP server to provide the sinkhole IP for DNS to the 'iot' DHCP clients.
Optionally add firewall rules to allow regular DNS to the sinkhole from the 'iot' devices but be blocked elsewhere including the C7 itself.
It this looks like what you want and the C7 is the DHCP server, then the following might do it:
In the Luci network page: (Select "Interfaces" in the "Network" menu) https://192.168.1.1/cgi-bin/luci/admin/network/network (Change the IP address as appropriate for your C7)
Click the "Edit" button on the 'iot" interface.
Click on the "Advanced Settings" tab.
Type in the IP address of your sinkhole in the data entry box for "Use custom DNS servers".
Click the "Save" button and check for error messages.
When back out at the "Network" page in Luci, click "Save and Apply" and check for error messages.
Reboot all your 'iot' clients connected to the 'iot' network and test.

If the above doesn't fit your use case then see the OpenWrt guides and forum posts on pi-hole and also "blocking DNS" or whatever fits your use case for specifics.
These might be a starting point for your searches:

Once you have your new 'iot' network working with connectivity, it may be good to mark this thread "Solved" and open new question threads specific to any additional DNS sinkhole or firewall question etc.

Good Luck!

I've set it up, but it's buggy - it handles only one client correctly. After that it fails to give out IP addresses via DHCP.

Supposedly is the integrated switch at fault here, I will buy a switch and an AP to solve the problem it seems.

I'm not familiar with the Archer series so if you know there is a problem with the switch supporting DHCP then by all means look at alternatives.

That might not solve your problem. A switch and an AP doing just wifi relying on DHCP from the C7 connected to the integrated switch on the C7 may leave you in same situation.
If your C7 is getting old and/or is barely meeting the RAM or flash size, you may want to consider replacing it as it might not be supported in a near future release as kernels/drivers etc keep getting larger.
I did a quick search on DHCP issues with wifi on Archer C7 and the situation I found had a workaround. You might look deeper or ask for help on your setup and not spend any money on new hardware.

This post and the three posts following it provide a high level blueprint for something a little more complicated than what you want to accomplish, and the main router in the example is using DSA, and your C7 is still on swconfig. So there are some differences configuring the vlans in your network file and connecting your WiFi SSID's to the vlans. I recently set up a swconfig EA8500 for a friend, so I'll post that configuration in a little bit, but this will get you started with the basic ideas.

It is much easier, at least for me, to do this from the command prompt and edit the network, dhcp, firewall and wireless configuration files in /etc/config directly. It can be done from luci, but there are a lot of luci menus to click through to make it all happen.

If you do not know how to get to the command prompt on your router and edit configuration files, there is no time like the present to learn if you are going to keep using OpenWrt :wink:

Click here for more detail to see an example login to edit the network file.
# ssh root@192.168.1.1
root@192.168.1.1's password: 


BusyBox v1.35.0 (2023-01-25 15:45:14 UTC) built-in shell (ash)

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt 22.03.3, r20028-43d71ad93e
 -----------------------------------------------------
root@EA8500-1:~# cd /etc/config
root@EA8500-1:/etc/config# vi network

If you do not know how to edit text files with vi, some find the nano editor easier to use. Here is how to install that:

opkg update
opkg install nano

Configuration files for a basic all-in-one gateway WiFi router on swconfig (not DSA) with LAN on VLAN 1, WAN on VLAN 2, Internet of Things Network on VLAN 10 and Guest network on VLAN 20 follow.

Cautions and Notes:

  • The swconfig example is based on an EA8500. In this example, the WAN is tagged to CPU port 0 ("0t"), and the LAN, GST and IOT networks to CPU port 6 ("6t"). Pay attention to how this is set up on your C7 and adjust accordingly in your network file.
  • For completeness, a network file showing the setup for a device migrated to DSA is also provided. The dhcp, firewall and wireless files are from the EA8500 swconfig example, but these three files do not materially differ between swconfig and DSA.
  • The network files are configured to send only lan traffic (untagged) to physical ports 1 and 2, IOT traffic (untagged) to port 3 and GST traffic (untagged) to physical port 4. Obviously configure this however you like it is just an example.
  • Do not use these files as direct replacements! Use them as guides. For example MAC addresses in the network file have been over-written with xx:xx:xx:xx, etc. That won't work well :wink:
  • Notice configuring br-lan, br-GST and br-IOT bridges for these VLANs in the EA8500 swconfig network file is more complicated than in the DSA example, but these bridges are needed to connect up the WiFi SSID's for each VLAN.
/etc/config/network (this example is for a device still using swconfig)
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 'xxxx:xxxx:xxxx::/48'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'eth1.1'

config device
	option name 'eth1.1'
	option macaddr 'xx:xx:xx:xx:xx:xx'

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 device
	option name 'eth0.2'
	option macaddr 'xx:xx:xx:xx:xx:xx'

config interface 'wan'
	option device 'eth0.2'
	option proto 'dhcp'

config interface 'wan6'
	option device 'eth0.2'
	option proto 'dhcpv6'

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '1 2 6t'
    option description 'LAN'

config switch_vlan
    option device 'switch0'
    option vlan '2'
    option ports '0t 5'
    option description 'WAN'

config switch_vlan
    option device 'switch0'
    option vlan '10'
    option ports '3 6t'
    option description 'IOT'

config switch_vlan
    option device 'switch0'
    option vlan '20'
    option ports '4 6t'
    option description 'GST'

config device
    option type 'bridge'
    option name 'br-IOT'
    list ports 'eth0.10'

config device
    option type 'bridge'
    option name 'br-GST'
    list ports 'eth0.20'

config interface 'IOT'
    option proto 'static'
    option ipaddr '192.168.10.1'
    option netmask '255.255.255.0'
    option device 'br-IOT'

config interface 'GST'
    option proto 'static'
    option ipaddr '192.168.20.1'
    option netmask '255.255.255.0'
    option device 'br-GST'

/etc/config/network (this example is for a device migrated to DSA)
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 'xxxx:xxxx:xxxx::/48'
	option packet_steering '1'

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

config bridge-vlan
	option device 'br-lan'
	option vlan '1'
	list ports 'lan1'
	list ports 'lan2'

config bridge-vlan
	option device 'br-lan'
	option vlan '10'
	list ports 'lan3'

config bridge-vlan
	option device 'br-lan'
	option vlan '20'
	list ports 'lan4'

config interface 'lan'
	option device 'br-lan.1'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'

config interface 'IOT'
	option proto 'static'
	option device 'br-lan.10'
	option ipaddr '192.168.10.1'
	option netmask '255.255.255.0'

config interface 'GST'
	option proto 'static'
	option device 'br-lan.20'
	option ipaddr '192.168.20.1'
	option netmask '255.255.255.0'

config interface 'wan'
	option device 'wan'
	option proto 'dhcp'

config interface 'wan6'
	option device 'wan'
	option proto 'dhcpv6'

Now we need DHCP servers for our new GST and IOT VLANS. Just the last two sections at the end for GST and IOT need to be added.

/etc/config/dhcp
config dnsmasq
	option domainneeded '1'
	option boguspriv '1'
	option filterwin2k '0'
	option localise_queries '1'
	option rebind_protection '1'
	option rebind_localhost '1'
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option nonegcache '0'
	option authoritative '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
	option nonwildcard '1'
	option localservice '1'
	option ednspacket_max '1232'
	option confdir '/tmp/dnsmasq.d'
	list server '/use-application-dns.net/'

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option dhcpv4 'server'
	option dhcpv6 'server'
	option ra 'server'
	option ra_slaac '1'
	list ra_flags 'managed-config'
	list ra_flags 'other-config'

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'

config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/hosts/odhcpd'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'

config dhcp 'IOT'
	option interface 'IOT'
	option start '100'
	option limit '150'
	option leasetime '12h'
	list ra_flags 'none'

config dhcp 'GST'
	option interface 'GST'
	option start '100'
	option limit '150'
	option leasetime '12h'
	list ra_flags 'none'

Next we need to set up firewall zones and rules so that our GST and IOT networks can get DHCP and DNS service. The additions start with: config zone....option name 'iot'.

/etc/config/firewall
config defaults
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option synflood_protect '1'
	option flow_offloading '1'

config zone
	option name 'lan'
	list network 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'

config zone
	option name 'wan'
	list network 'wan'
	list network 'wan6'
	option output 'ACCEPT'
	option masq '1'
	option mtu_fix '1'
	option input 'DROP'
	option forward 'DROP'

config forwarding
	option src 'lan'
	option dest 'wan'

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-Ping'
	option src 'wan'
	option proto 'icmp'
	option family 'ipv4'
	list icmp_type 'echo-request'
	option target 'DROP'

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

config zone
        option name 'iot'
        option output 'ACCEPT'
        option forward 'REJECT'
        list network 'IOT'
        option input 'REJECT'

config zone
        option name 'gst'
        option output 'ACCEPT'
        option forward 'REJECT'
        list network 'GST'
        option input 'REJECT'

config forwarding
        option src 'gst'
        option dest 'wan'

config forwarding
        option src 'iot'
        option dest 'wan'

config rule
        option name 'Allow-iot-DNS'
        option src 'iot'
        option dest_port '53'
        option target 'ACCEPT'
        list proto 'tcp'
        list proto 'udp'

config rule
        option name 'Allow-gst-DNS'
        option src 'gst'
        option dest_port '53'
        option target 'ACCEPT'
        list proto 'tcp'
        list proto 'udp'

config rule
        option name 'Allow-iot-DHCP'
        option target 'ACCEPT'
        list proto 'udp'
        option src 'iot'
        option dest_port '67-68'

config rule
        option name 'Allow-gst-DHCP'
        option src 'gst'
        option dest_port '67-68'
        option target 'ACCEPT'
        list proto 'udp'

Finally, let's attach some unique WiFi SSID's to our new Guest and Internet of Things VLANS.

/etc/config/wireless
config wifi-device 'radio0'
	option type 'mac80211'
	option path 'soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0'
	option channel '1'
	option band '2g'
	option htmode 'HT20'
	option disabled '0'
    option country 'US'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option ssid 'OpenWrt-2G'
    option encryption 'psk2+ccmp'
    option key 'TopSecret'

config wifi-device 'radio1'
	option type 'mac80211'
	option path 'soc/1b700000.pci/pci0001:00/0001:00:00.0/0001:01:00.0'
	option channel '36'
	option band '5g'
	option htmode 'VHT80'
	option disabled '0'
    option country 'US'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option ssid 'OpenWrt-5G'
    option encryption 'psk2+ccmp'
    option key 'TopSecret'

config wifi-iface 'wifinet2'
        option device 'radio0'
        option mode 'ap'
        option encryption 'psk2+ccmp'
        option key 'TopSecret'
        option network 'GST'
        option ssid 'OpenWrt-2G-Guest'

config wifi-iface 'wifinet3'
        option device 'radio0'
        option mode 'ap'
        option ssid 'OpenWrt-2G-IOT'
        option encryption 'psk2+ccmp'
        option key 'TopSecret'
        option network 'IOT'

config wifi-iface 'wifinet4'
        option device 'radio1'
        option mode 'ap'
        option ssid 'OpenWrt-5G-Guest'
        option encryption 'psk2+ccmp'
        option key 'TopSecret'
        option network 'GST'

config wifi-iface 'wifinet5'
        option device 'radio1'
        option mode 'ap'
        option ssid 'OpenWrt-5G-IOT'
        option encryption 'psk2+ccmp'
        option key 'TopSecret'
        option network 'IOT'

1 Like

What do the values stand for? 1 untagged, 2 untagged, 6 tagged?

Yes, you have it right.

In this example:

  • Ports 1 and 2 are the first and second lan ports on the back of the device
  • Ports 1 and 2 are untagged and port 6 is the CPU, which is left tagged as in the default OpenWrt configuration.
  • The "t" after the port number designates "tagged" on swconfig devices. On a DSA device, you would tag with ":t" like this instead:
list ports 'lan2:t'
  • The main LAN is assigned to ports 1 and 2 untagged. Since no other VLANs are assigned to these ports in the rest of the configuration, tagging is not necessary for devices plugged into these ports to distinguish which packets belong to which VLAN. In this example, devices plugged in to lan ports 1 or 2 on the back of your router do not even need to be VLAN capable - they will only see the main lan, because ports 1 and 2 have only the main LAN assigned to them.

Now notice port 3 is mapped only to IOT and port 4 is mapped only to Guest. In this example, if you plug a device into lan port 3, it can only see the IOT network, nothing else. Similarly, a device plugged into lan port 4 can only see the Guest network and no other. Again, they are not tagged, since no port has access to more than one VLAN. If you would like lan port 4 to access both IOT and Guest vlans, then you would need to add port 4 to the list, and at least tag it so the two VLANs can be distinguished from each other (you could tag 3 and 4 also - it all depends how you want to set up your network), like this:

config switch_vlan
    option device 'switch0'
    option vlan '10'
    option ports '3 4t 6t'
    option description 'IOT'

A common variation of this theme is plugging a second VLAN capable all-in-one wifi router to function as a dumb AP on the other side of your home (or another floor) into your main all-in-one router, attached by a very long Ethernet cable wire run. Let us assume you are plugging this device into lan port 1. In this case, you would probably want to map lan port 1 to every VLAN on your network tagged (technically, you could not tag the port under one of the VLANs, but only one could remain untagged). This way the second all-in-one router can have access to every VLAN on your home network, thus its WiFi SSID's can be on the exact same networks as the main router. The tagging allows it to distinguish the VLANs from each other and segregate them.

In this example, the WAN is tagged to CPU port 0 ("0t"), and the LAN, GST and IOT networks to CPU port 6 ("6t").

Isn't Port 6 WAN though? Also would it be possible to make a GUI tutorial? This manual config editing seems to bug me out, since I don't know what's relevant to my hardware and what's not.

The sentences before and after what you quoted are key.

On an EA8500, port 5 is the WAN port-actually it is labeled "Internet" on the back of the router. Here it is in the network file:

config switch_vlan
    option device 'switch0'
    option vlan '2'
    option ports '0t 5'
    option description 'WAN

and ports 1 through 4 (labeled 1 through 4 on the back of the router) are the LAN ports. Here in the network file is where LAN ports 1 and 2 are assigned to the main LAN VLAN network.

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '1 2 6t'
    option description 'LAN

If you get things in a jumble, reset your C7 to defaults and stare at the network file a bit - it will eventually make sense. Your C7 may assign the same switch/CPU port to your WAN and LAN, or different ones like on the EA8500 (0 and 6 on the EA8500). The default configuration will assign 1 port to your WAN, and the other 4 to your LAN.

There are already GUI tutorials to be found on you tube and web pages elsewhere, and they take quite a bit of effort to produce. It may not feel that way now, but it's worth the effort to learn to use the configuration files when configuring more than a few simple changes easily captured in a screen shot or two.

1 Like